80
Low effort meme
(lemmy.nz)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 15 Sep 2025
80 points (88.5% liked)
Programmer Humor
43653 readers
208 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 7 years ago
MODERATORS
To be frank: You gain the information that
MyConcreteType::get<uint32_t>returns auint32_t, which I otherwise couldn't infer from the docs. Of course, I could assume it, based on the template parameter, but I don't want to go around assuming a bunch of stuff in order to read docs.Take an example like
auto x = my_var.to_reduced_form(), it's very clear thatxis the "reduced form" ofmy_var, which could be meaningful in itself, but what type is it? I need to know that if I want to do anything withx. Can I dox += 1? If I do, will that modifymy_var? Let's say I want to make avectorof whateverto_reduced_formreturns... and so on.All these questions are very easily answered by
MyConcreteType x = my_var.to_reduced_form(). Now I immediately know that everything I can do withmy_var, I can also do withx. This makes me happy, because I need to do less digging, and the code becomes clearer to read.To answer you: no,
x += 1cannot mutatemy_var, because it’s a copy. If you wanted something else you would sayauto&orauto*.And if the type of
xis such that even a copy can mutate the original (e.g. maybe it’s a wrapper around an index with an overloadedoperator+=()that mutates the original entry in the storage), you are probably working with a specialized system of some kind, since that breaks the semantics of the language, and hopefully you would know from context that you have such cases.And yes, in such an environment I would see “never use auto for this wrapper type” as a valid additional strategy to help ensure code correctness.
But by and large my direct experience is that using auto “almost always”, as Herb Sutter puts it, is beneficial and doesn’t harm readability or understandability.