I read two C++ subreddit threads today on using the auto keyword. They’re both questions: the first one asks why certain people seem to dislike using type inference, while the second asks about what commonly taught guidelines should be considered bad practice. A few replies there mention auto.
This confuses me for more than one reason. The first is that I’m a big proponent of type inference. Having to work to tell a computer what it already knows is one of my pet peeves. I also believe that wanting to know the exact type of a variable is a, for lack of a better term, “development smell”, especially in typed languages with generics. I think that the possible operations on a type are what matters, and figuring out the exact type if needed is a tooling problem that is solved almost everywhere. If you don’t at least have “jump to definition” in your development environment, you should.
The other main source of confusion for me is why this debate seems restricted to the C++ community, at least according to my anectodal evidence. As far as I’m aware of, type inference is taken to be a good thing almost universally in Go, D, Rust, Haskell, et al. I don’t have statistics on this at all, but from what I’ve seen so far it seems to be the case. Why is that?
One reason might be change. As I learned reading Peopleware, humans aren’t too fond of it. C++ lacked type inference until C++11, and whoever learned it then might not like using auto now; it’s “weird”, so it must be bad. I’ve heard C programmers who “like” looping over a collection using an integer index and didn’t understand when I commented on their Python code asking them to please not do that. “Like” here means “this is what I’m used to”. Berating people for disliking change is definitely not the way forward, however. One must take their feelings into account if one wants to effect change. Another lesson learned from Peopleware: the problem is hardly ever technical.
Otherwise, I’m not sure. I’m constantly surprised by what other people find to be more or less readable when it comes to code. There are vocal opponents to operator overloading, for instance. I have no idea why.
What do you think? Where do you stand on auto?
Átila on Code 
> One must take their feelings into account if one wants to effect change
Umm, who are you and what have you done to the Átila I know? 🙂
I’m older and hopefully wiser!
I took the opportunity and posted my comment in the subreddit you mention: https://www.reddit.com/r/cpp/comments/bgmf59/why_do_some_people_dislike_auto_and_what_would/eo99cfu?utm_source=share&utm_medium=web2x
Nice post. For short time I’ve been proponent of explicitly written types. The reason was that my “Jump to definition” worked really bad. I was using VS2019 on large codebase and when I wanted to see what the type was I had to wait for +30sec for something to happen. So it was easier to just write the type then look it up. All in all just a pathetic experience. Now with Clion I can see the type instantly so auto is pretty much everywhere. I didn’t try emacs yet!
Editors aside, what really moved me towards using auto was refactor where I changed underlying type in couple of places and ou boy, did I get compile errors. I’ve noticed then that I got them mostly because I’ve used explicit type, not the wrong API.
As for python index-based loops: Introduce them to
“`py
import this
“`
“`
Beautiful is better than ugly. <— THIS
Explicit is better than implicit.
Simple is better than complex. <— THIS
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts. <— THIS
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it. <— THIS
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!
“`