[theyoungestgun]

Agreed - but this is why modern features should be paired with modern tools. A simple hover-over or click through in an IDE to show what the function signature looks like is pretty basic these days. Autocomplete on what that auto variable's API offers getting better and better as well.

[pasas]

How does autocomplete and tooltips help you when diffing/merging code? It doesn't.

Relying on IDEs to give you insight into what should be obvious by just looking at the code show's that something's wrong IMO.

[theyoungestgun]

I do not consider the API of a reasonably complex construct "obvious". That is often where IDEs shine for me - in java or any other language that can gather that info for me. It's scenarios where I don't have to go to cppreference.com, because the IDE is going to give me what I want directly.

I used to really be anal on making every single line explicit: no shortcuts. But over time, especially with increasing my usage of templates, I've come to relax on these things and prefer to put my efforts in good variable names and trusting the compiler.

I'm not saying you should use auto for basic types (especially ones that can be easily cast into each other - that shit gets dangerous). I am saying that auto is extremely powerful when working with most interesting APIs. The most recent example I have is a lot of things I end up doing with chrono.

[Aleman360]

> How does autocomplete and tooltips help you when diffing/merging code? It doesn't.

Sounds like there's an opportunity for better diff tools.

[dysfunction]

There really is... diff tools that point to the compiler (or a parse tree for dynamically-typed languages) could be so much smarter than what we have now.

[Skunkleton]

From my perspective this is fundamentally flawed logic. Why would you want to depend on a tool when you don't have to? Why would I want to hover over all sorts of auto variables to figure out their type when I could just read it instead?

[mannykannot]

Speaking as someone who has done a lot of C++ work with nothing more than Emacs, I don't think there is any particular value or virtue in using only the sort of tools that were available in the 80s. The problem of finding out exactly what sort of thing you are dealing with did not start with auto (the elements of expressions have never been labeled with their type), and I think better tools are the way to the solution. C++ is actually a good language for this, as as little as possible is left to be decided at runtime.

With regard to the hovering issue specifically, there can be a great deal of visual clutter from type names that is a hinderance to understanding most of the time; now you only have to see it when you need it. That is only the start, however; a decent IDE should, for example, make it easy to go from there to the declaration of the type, should you want to.

[theyoungestgun]

"When I don't have to"

If I'm not going to depend on the IDE to tell me what a deduced variable type is, you can bet your ass I'm going to want to depend on it for autocompleting some of the insanely long type names are: std::chrono::steady_clock::time_point gets old real quick - and so does stead_clock::time_point (if you want to include the namespace).