|
|
|
|
|
by mlthoughts2018
2917 days ago
|
|
> “It has been demonstrated several times in this thread that there clearly are cases where the types can be deduced effortlessly and avoiding explicit information leads to cleaner code.” I do not see a single example in this thread that demonstrates that. Absence of explicit type info is an inherently bad thing. It’s never good to offer code readers less explicit / more ambiguous info. Like I said, you’d expect some offsetting benefit (what you call “cleaner code”) to compensate for paying the penalty of giving up valuable explicit info. But auto does not actually provide that in comparison to typedef/typename. auto, by comparison, is not meaningfully cleaner code. It only loses valuable explicit information, without an offsetting benefit that couldn’t otherwise be obtained without losing that valuable explicit information. |
|
Let me reiterate: It is your opinion which many people here do not agree with in the context of types obvious from context. Your opinion is definitely not a popular coding standard and definitely not a fact. Most of the coding standards are in favor of using auto for simple code where the type is immediately obvious from the context.
The auto keyword is available to help people who do not share your opinion. The auto keyword is present for teams which agree that absence of explicit type info is a good thing for simple code with obvious types (obvious from the context).
Teams that believe that absence of explicit type info is an inherently bad thing don't have to use the auto keyword. But that belief does not become a fact no matter how many times you reiterate that belief.
> paying the penalty of giving up valuable explicit info
That's your opinion. My opinion which many coding standards agree with: There is no penalty in giving up explicit type info in a local loop variable. The typo info is not valuable in that case.