I also flinched at the advice to use 'auto' wherever possible. When I'm doing some refactoring I prefer to have the compiler throw errors and warnings when types change. Let's say I have a method which returns a map<int,int> written as auto:

auto bla = obj->GetBla();

bla[x] = y;

The assignment adds a new element or overwrites an existing element to the map, it will never crash.

Now during a refactoring obj->GetBla() is changed to return a vector<int>. In conventional code the build would break with an incompatible type error, the coder investigates, sees what's wrong and fixes the problem. With the auto statement the code would compile, but the bla[x] = y; would very likely not do what was intended (it can overwrite foreign memory or produce a segfault).

Is this not seen as a problem? I do use auto here and there where the type is obvious (for instance written on the right-hand-side of the assignment), but using 'auto wherever possible' is terrible advice IMHO, since it completely undermines type safety.

[edit: typos and formatting]