So the auto keyword is wonderful isn't it? Maybe, maybe not. Whilst it can reduce the clutter when dealing with long type names, especially with templates, it has a few disadvantages.
This would be wrong, because what you want is a constant iterator into the container, since you are not changing it. There are two ways to fix it, by using a for each loop or cbegin and cend. With a for each loop you get a reference to the item.
when you actually want the iterators, you can use auto iter = c.cbegin().
What size type do you want?
are you sure you want sizes for i and f that the compiler will give you? If you want i to be unsigned, and f to be a double, then you might not get what you want. Then your code might also break on another platform.
If you use auto too much, then you will come back to your code next week and not have a clue what you have written. If every object is declared with auto, then you have no idea what is going on, and it might be easy to make a mistake, or get lost in fixing your code. As much as auto can unclutter your code, type names are also documentation.
What is my return type?
It might seem nice to not have to declare the type of some convoluted long template expression, so you use auto and decltype for a trailing return type. But, you have copied and pasted your long expression, and if you change the return expression but not the type, such that they are still compatible, but not what you want, then you have a problem. You might want to return a copy, but you return a reference, for example, and your trailing return type hides that.
The first line declares an integer x, no problems there. The second line declares y to be a reference to x. Even though y is a reference type, the third line declares z to be a copy of y. The fourth line is wrong, because you cannot declare a reference to an r-value.
When you use auto, it is important to make sure that your reference type is correct. Just because the right-hand side is a reference, it doesn't mean that the declared variable will be a reference, you have to specifically ask it to be.
z is not a reference, just a copy of y. The last line won't compile.
The return type issue is fixed in C++14: you can omit the trailing return type at all in most cases.
So, honestly, I don't consider auto harmful, just convenient.
Well there you go. I was trying to point out things to be careful of, rather than people thinking that auto is some magical keyword that solves everything. Its behaviour is well defined, like everything that is defined by the standard, but if you don't know what it is, then it is easy to get wrong. We have a tool that lets us blow our whole foot off, or something like that.
I've edited the post to fix my forgetting that cbegin existed.
Of course, I would not use it for int either. Yes, it is useful for very complicated expressions. I am just suggesting that it be used with care. Thanks for the link.
"const iterators" – That's why C++11 has cbegin() and cend().
"What size type do you want?" – Use type suffixes; 10u and 4.5f. I would strongly suggest doing that anyway.
"What are my types?" – This argument is fundamentally at odds with the established programming advice "program to an interface, not an implementation". That said, I don't think that the concern completely meritless but in practice it often isn't an issue, and it's even beneficial to be type agnostic. C++ already does that with templates, and all OOP languages do it with interfaces/base classes.
"What is my return type?" – This point is correct but it's unrelated to use of auto: you would use such code when you cannot write the return type otherwise. In other words, in this case you don't have a choice anyway. And yes, it's not an ideal situation, which is why C++14 adds return type deduction.
"To reference, or not to reference?" – This can be alleviated greatly by using universal references. But in general, you always have to think about references, auto or no auto.
Many of these points have already been addressed in great detail by Herb Sutter in GotW #94 (aka. "AAA"). In fact, AAA's discussion is so complete that, at this point, I believe that any discussion of auto more or less has to refer to this article, and its arguments.