> In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. You'd have to go

> In a language designed for humans, the simplest expression of a loop (e.g. `for (auto paths : m) {}`) would use references not value copying. You'd have to go out of your way to do the it the dumb way, which you would only do when you have a specific reason to do so. But I would expect auto x = y; to create a new variable by copying with type-deduction from y, not a reference (or even const reference) to y. If I want a reference anywhere in the language I always have to say so explicitly. As such, I find it perfectly normal that for(auto x : y) create a copy of the elements of y while for(auto& x : y) creates a reference to the elements of y. Reversing this just within for-loops would only add to the confusion. Defaulting to references over values just for auto where everywhere else values are the default and references need to be specified would also only add to the confusion. Of course you may now say that one should have done it right from the start, but this is then an argument about the initial decisions in the late 80s, not about the use of auto in C++11. Regarding the specification, I am incredibly happy that there is a specification I can trust and nowadays a series of different compilers which largely implement this specification instead of some "model-implementation" which implicitly defines the language and may look entirely different next week.