Heh this is normally why I tell my new teammates to be careful about using auto in non-test code outside of well established patterns like iteration. Auto will bite everybody in the butt at some point!
We don't got time for non-auto. Better yet, we should've just written all our stuff in Python or Java. We have no legitimate need (performance etc) for C++, Rust, or even Golang.
Even if you use string_view on the LHS instead of auto, pretty easy to miss the bug here.
Same here. I avoid auto in my code except iterations. Just a mental pattern. I understand that people coming from "typeless" languages might not like it at all, but it is like with guns. You can play with water pistol but you do not play with real guns, you follow some rules if you want it safe. Modern C++ in my opinion supplies enough features and tooling to help with making reasonably sure the rules are followed.
Citation needed? My team generally avoids auto and tends to spell out the types most of the time, which we find makes everything more readable. Code is written once but read many times...
Notice that he says "the main reasons to declare variables using auto are for correctness, performance, maintainability, and robustness—and, yes, convenience, but that’s in last place on the list.". He is arguing literally the opposite of what you do, that using auto avoids bugs ("for correctness").
I'm not going to argue in favour or against "Almost Always Auto". But I see no problem calling it "Modern C++".
imo types don't make things more readable. You know the "fluent programming" thing where you do obj.doThis().doThat().doThis().doAnotherThing() and probably 20 more lines of this? That's entirely because people didn't want to bother writing out LHS types, but whatever version of the language only let you avoid that if you chained things (there was no auto or var). Maybe it's more of a Java practice, though.
Our style guide says "almost never auto," but most people auto everything. They can make the linter replace auto with the actual type if it's really that big a deal. Explicit type wouldn't have avoided this bug.
Arguably an explicit type would have made the bug a little bit more obvious. You basically expect, by default, this kind of string manipulation functions to return a std::string. Obviously in this specific case you can return a view, and that makes it more performant; but it's kind of unexpected and using auto leaves the surprise a bit more hidden.
But sure, you can still make the error with expiclit types.
