5 ms·
Yes, auto is definitely welcomed in the case of my::long::scoped::namespace::templatedItem<more::details::here>::const_iterator but using it for member function
by 72deluxe 9y ago
Yes, auto is definitely welcomed in the case of my::long::scoped::namespace::templatedItem<more::details::here>::const_iterator but using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left.
Of course, in the case of types that are the results of other templated types e.g. T,U -> V then it makes sense and it is obviously welcomed in the syntax of lambdas (far more sensible to me than the C# syntax or C#'s Func) but the use of it everywhere seems foolish.
If it were a good idea, then we would be pushing to remove the return type being at the beginning of a function at all; please say this isn't the case!
eg.
main(int arg, char* argv[]) -> int
or complete stupidity that makes it impossible to read without an IDE (e.g. in a diffing tool):
auto main(auto arg, auto* argv[])
When it turns into that, I'm quitting the industry.
- AboutTheWhisles 9y ago> using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left This is not what auto as a function return type is for. Auto wasn't invented so people could put int on the right side of a function. There are two reasons to use it. The first is similar to using auto for a long type name. You can use decltype to declare the return type to be the same as the resulting type of an expression. The second is what you mentioned, keeping in mind that you can use template types in the decltype expression.