[germandiago]

There are thing that cannot be even named. Or nested types in C++ that are super long. auto says nothing about its type, but:

``` forward_iterator auto it = ...; ```

shows intention. Auto has saved me lots of headaches, particularly in generic code: what is the type of some arithmetic operation? Type inference can help. What is the return type of a lambda? auto helps, it is impossible to spell. What is the result of a non-type-erased range view pipeline? Almost impossible to get right.

There are lots of examples where auto is valuable at least in C++.

[freedomben]

I mostly agree with you fwiw. I don't think type inference as a whole is a mistake, and especially regarding local variables I think it can make things a lot cleaner and save unnecessary work.

My main problem with it (in general, not specifically C++) is that most implementations leave it up to people's judgment about when and where to use it, and they almost always use it too liberally. This is a mistake I make myself because it's not usually clear at write-time where the readability cost will out-weigh the benefit, and when the code is freshly in your head you don't need the extra information that comes from explicit typing (and indeed it can feel superfluous).

But I think it's worth pointing out that the GP comment on this thread (which I was replying to) was essentially advocating for maximum type inference because the IDE can show you at any time what the type is, so any explicit typing is superfluous to them.

[AnimalMuppet]

> There are thing that cannot be even named.

Um, can you give me an example? (Can you give an example without naming it?)

Types that cannot be written, or are too long to be reasonably written, are likely to also be too hard to really understand. Maybe their existence should be regarded as a code smell.

[germandiago]

The type of a lambda cannot be spelled. The type of a local class return cannot be named from outside either.

[AnimalMuppet]

By "local class return", do you mean a function that returns what Java calls an "inner class"? That's perfectly describable (in C++ as well) if the inner class is public rather than private. It's unnameable, not because of the type, but because of the access (private).

[germandiago]

You can create a class inside a function and return an object of it. That name is not legal outside of the function but its methods can be called.

[AnimalMuppet]

Ah, I see. Inner to the function, not inner to the class. So the C++ syntax would need to be something like:

  ClassName::functionName::innerName

Except that's not an actual C++ syntax - there isn't one.

But if you return it from a function, how do you declare the variable you assign it to? auto?

And, is auto a valid return type from a function? If not, how do you declare the function that returns this object?

[germandiago]

Exactly. You spell auto or an interface or base class whose derived class cannot be named. I think both are ok. In the latter case you can name the interface instead of auto.

Yes, auto is a perfectly valid return type, usually quite useful in generic code.

However, in generic code, starting at C++20, I would recommend to use concepts to name a return type that can be many different thing but that is compliant with the same "compile-time" interface.

You could do:

    forward_range auto f(auto && input);

You do not spell the return type but you are saying that type conforms to forward_range. Note that the auto type returned could be one of many unrelated types and it is computed at compile-time.