Hacker News new | ask | show | jobs
by freedomben 807 days ago
As a vim user, I have the same problems. I don't even have a mouse to hover over symbols either to see what their type is.

But even when I've used IDEs in the past, type inference still seems an unnecessary slowdown and pain in the ass to save 1 second of typing. Explicit types make the code a lot more readable, even if your IDE is capable of showing you the type.

1 comments

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++.

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.

> 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.

The type of a lambda cannot be spelled. The type of a local class return cannot be named from outside either.
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).
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.
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?