Your local style guide can’t override this?

Just turn people loose on your codebase without supervision and be really surprised that the hackers make off with your data?

You, sir, are arguing from bad faith as your obvious mission is to promote “rust in all the places”.

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.

I agree, the string_view on the LHS might make you think more about the lifetime, but I'm pretty sure we all would've missed it.

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...

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.

A citation of what's "Modern C++"? The term is a made up concept with no proper definition...

But "Herb Sutter says you should use it, he even gave it a catchy name/acronym" is as good as it gets. And he does so AFAIK in the same place he created the "Almost Always Auto" name: https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style...

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++".

* Herb Sutter being the convener of ISO WG21