Good point about robustness, it makes sense in the general case, but if I have a container of integers, I think the chance that I replace int with a more expensive type while not having to modify the rest of the loop is pretty unlikely. Chances are the more expensive type would no longer behave like an int. I think there are cases where the robustness approach shines, and cases where it's pretty safe to just use a const copy and a reference would just add noise. Imagine a simple function where I initialize an array of integers, then iterate over them. const auto or just const int makes sense, const auto& requires more explanation and invoking what if's that are unlikely to ever surface.

But be careful about the lifetime of the object referenced! Just because its 'const' doesn't mean it cant go out of scope.

Local const reference prolongs the object lifetime[1]. There shouldn't be any problems whenever you use it in a for loop.

[1]: https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-th...

There definitely can be problems: the reference may escape the for loop, and the reference may be invalidated by a modification of the container (even for something "stable" like ordered_map, the referent may be removed).

If a pointer/reference escapes the loop you'll have problems whether the thing to the right of the colon is a reference or a copy. If it's a copy, the escaped reference will definitely be invalid once that iteration complete. If it's a reference, it will remain valid in more situations.

Yes, I believe that's what I was saying, but your comment sounds like it is disagreeing. Could you clarify?

Oh, okay, then. I thought you were saying that that was a problem specific to iterating by reference.

references prolong the lifetime of temporaries. It wouldn't work in this case:

vector<int> v =...; const auto& x = v[59]; v.clear(); // x is dangling