3 ms·

It depends on the situation. Using the 'auto' keyword makes things more generic. It can also save long type names from making expressions difficult to read. A

It depends on the situation. Using the 'auto' keyword makes things more generic. It can also save long type names from making expressions difficult to read. An IDE that can follow the auto to its actual type is also helpful. If a type name is small then being explicit about the type name can be much more clear since it can save someone having to hunt down what type each function might return.

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.

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.