> add a postfix type if inference can't do the job for a reason or another
Ehh... not putting a return type in at all is a bridge to far IMO. Be friendly to the casual reader of the code, and help them understand what the function returns. (Yes I know IDE's can do this for you, but not everyone uses an IDE, and not everyone is reading the code in the context of an IDE... for instance code review, etc.)
Ehh… not using an IDE is a bridge too far IMO. Be friendly to the casual writer of the code and help them express themselves without having to repeat the obvious.
(Yes, I know, we write less time than read, but maybe that is what is actually wrong with the tools we use?)
Mandating or expecting tools for others is a problem. Many code reviews are done in web settings, and that was an example you ignored fromt he person you responded.
And you ignored any value that actually specifying the type can have.
You also ignored the age old wisdom that code is written once and read many times.
Why are you attacking me? I just put some motivation for myself and maybe someone else to switch to an IDE.
Is this mandating tools thing a problem where you are working?
How did that affect you?
Why do you feel attacked? You aren't your ideas, and in this case you had a bad idea.
You said that people not having an IDE was "bridge too far" meaning that people should always have them. We already had examples of where that simply isn't true so your idea was demonstrated as wrong. Own it get a better idea and move on. I certainly had until I went through my past comments looking for childiah arguments and found one.
Those cases are the ones for which the explicit return type was intended. And if the deduced type is counterintuitive you could also use the explicit return type (or a comment: there are good arguments for either choice).
But if your argument is "this makes the reader do extra work" then that's an argument against all uses of `auto`. Now I do consider reader clarity a legitimate (and important) design criterion (and argument in code review), but I don't think it is reasonable in this case.
In fact I consider type deduction with auto to be an important element of readability: it tells the reader not to worry about the type and focus on the logic. Then the cases when a type is explicitly specified it tells the reader that it's worth paying attention.
Ideally, functions should be clear at the call site without a reader having to jump to the declaration to understand what's going on, and you don't get the return type there in the first place.
Ehh... not putting a return type in at all is a bridge to far IMO. Be friendly to the casual reader of the code, and help them understand what the function returns. (Yes I know IDE's can do this for you, but not everyone uses an IDE, and not everyone is reading the code in the context of an IDE... for instance code review, etc.)