4 ms·

> If I come across a structured binding where x and y are auto assigned as the unpacking of struct fields whose types might be complicated, now I have local var

by susam 8y ago

> If I come across a structured binding where x and y are auto assigned as the unpacking of struct fields whose types might be complicated, now I have local variables x and y that I cannot reason about ... One is free to not use the auto keyword in a scenario like you mention in order to make the types explicit regardless of what the "Almost Always Auto" camp says. However there are scenarios where leaving the type out does not degrade readability and sometimes improves readability. Often cited examples of situations where it may improve readability usually look somewhat like this: void print_vector_of_maps(std::vector<std::map<std::string, std::string>> v) { for (const std::map<std::string, std::string>& item: v) { for (const std::pair<std::string, std::string>& entry: item) { std::cout << entry.first << ": " << entry.second << '\n'; } std::cout << "---\n"; } } With the auto keyword, it looks like this: void print_vector_of_maps(std::vector<std::map<std::string, std::string>> v) { for (const auto& item: v) { for (const auto& entry: item) { std::cout << entry.first << ": " << entry.second << '\n'; } std::cout << "---\n"; } } The types are still known from the surrounding context and the readability has arguably improved.

mlthoughts2018 8y ago
The auto example here looks strictly worse than just creating a descriptive typedef/typename to shorten the syntax of the first approach. I’m all for shorter syntax, just not at the expense of completely explicit type annotation.
- xyrouter 8y ago
  The usage of the word "strictly" here is strictly sloppy. Why is a typedef/typename better than using auto in this case? You can literally look up the actual type the auto keyword is deducing by looking at the function parameters two lines above. How many new typedefs do you want to create for code like this? You are suggesting creating two typedefs for this tiny 4-line code only. Imagine how many typedefs you might need to create in a real and complex project. How is the mess of typedefs going to be any more maintainable than this? There are places where the auto keyword would make it hard to understand the type and there are places where it won't. This is a place where the auto keyword does not make it hard to understand the type. Don't use the auto keyword if you don't want to but pretending that there is no value in using the auto keyword by using weasel words such as "strictly" is disingenuous.
  - mlthoughts2018 8y ago
    > “Why is a typedef/typename better than using auto in this case? You can literally look up the actual type the auto keyword is deducing by looking at the function parameters two lines above.” Because a typedef makes the syntax equally as short as auto in all practical senses, while keeping the item type explicit. Even when figuring out the item type only requires looking up a few lines, this limitation of auto is still worse while not providing any “terseness” advantage. And obviously ising auto as a kludge for a type of polynorphism where you switch around header files, etc., to arrange the upstream type to change and rely on other code’s use of auto to “just work” is a severe and critically flawed kind of anti-pattern. In most cases it won’t be anywhere near this easy anyway, the the type of the function parameter should already have had an application-specific typedef to understand its meaning, so the extra use in places where auto is used would amortize it further. And since you get much more benefit from the typedef way in more complex situations, it would be better style to just use it consistently by using it in simpler situationd too, especially since when the situation is simple, like this example, auto by definition doesn’t provide an advantage. This is why I specifically used the word “strictly” like the mathematical sense of strictly increasing or a dominated function. The typedef approach for this is superior unilaterally.
    - xyrouter 8y ago
      > In most cases it won’t be anywhere near this easy anyway Then don't use auto in such cases -- is the point of the discussion here. Use auto anywhere it is indeed nearly this easy. When the situation is simple, auto clearly provides an advantage of automatically deducing types that are very obvious to humans and the compiler. The argument here is that not having explicit types here is better. Your cannot use the word "strictly" here in the mathematical sense at all since you have not mathematically established that explicit types for simple cases are better. It is only your subjective opinion that explicit types are better even in simple cases and such an opinion is far from the exactness and axiomatic nature of mathematics. You pretend as if the proposition that "explicit types are better" is an axiom. It is not. To many of us such proposition is neither self-evident nor obvious because many of us believe removing explicit types for simple cases is better. As such, the usage of "strictly" here is merely a weasel word.

by susam 8y ago

mlthoughts2018 8y ago

The auto example here looks strictly worse than just creating a descriptive typedef/typename to shorten the syntax of the first approach. I’m all for shorter syntax, just not at the expense of completely explicit type annotation.

xyrouter 8y ago
The usage of the word "strictly" here is strictly sloppy. Why is a typedef/typename better than using auto in this case? You can literally look up the actual type the auto keyword is deducing by looking at the function parameters two lines above. How many new typedefs do you want to create for code like this? You are suggesting creating two typedefs for this tiny 4-line code only. Imagine how many typedefs you might need to create in a real and complex project. How is the mess of typedefs going to be any more maintainable than this? There are places where the auto keyword would make it hard to understand the type and there are places where it won't. This is a place where the auto keyword does not make it hard to understand the type. Don't use the auto keyword if you don't want to but pretending that there is no value in using the auto keyword by using weasel words such as "strictly" is disingenuous.
- mlthoughts2018 8y ago
  > “Why is a typedef/typename better than using auto in this case? You can literally look up the actual type the auto keyword is deducing by looking at the function parameters two lines above.” Because a typedef makes the syntax equally as short as auto in all practical senses, while keeping the item type explicit. Even when figuring out the item type only requires looking up a few lines, this limitation of auto is still worse while not providing any “terseness” advantage. And obviously ising auto as a kludge for a type of polynorphism where you switch around header files, etc., to arrange the upstream type to change and rely on other code’s use of auto to “just work” is a severe and critically flawed kind of anti-pattern. In most cases it won’t be anywhere near this easy anyway, the the type of the function parameter should already have had an application-specific typedef to understand its meaning, so the extra use in places where auto is used would amortize it further. And since you get much more benefit from the typedef way in more complex situations, it would be better style to just use it consistently by using it in simpler situationd too, especially since when the situation is simple, like this example, auto by definition doesn’t provide an advantage. This is why I specifically used the word “strictly” like the mathematical sense of strictly increasing or a dominated function. The typedef approach for this is superior unilaterally.
  - xyrouter 8y ago
    > In most cases it won’t be anywhere near this easy anyway Then don't use auto in such cases -- is the point of the discussion here. Use auto anywhere it is indeed nearly this easy. When the situation is simple, auto clearly provides an advantage of automatically deducing types that are very obvious to humans and the compiler. The argument here is that not having explicit types here is better. Your cannot use the word "strictly" here in the mathematical sense at all since you have not mathematically established that explicit types for simple cases are better. It is only your subjective opinion that explicit types are better even in simple cases and such an opinion is far from the exactness and axiomatic nature of mathematics. You pretend as if the proposition that "explicit types are better" is an axiom. It is not. To many of us such proposition is neither self-evident nor obvious because many of us believe removing explicit types for simple cases is better. As such, the usage of "strictly" here is merely a weasel word.