3 ms·

I’m not for sure auto is an improvement. I know it is required for lambdas and it makes it easier to type out a very verbose type, but it really does reduce cod

I’m not for sure auto is an improvement. I know it is required for lambdas and it makes it easier to type out a very verbose type, but it really does reduce code readability. I’ve even seen developers use it instead of bool, which is pretty laughable as the they are the same number of characters.

wk_end 2y ago
A verbose enough type - and C++ has plenty of those - is indistinguishable from line noise. There are places where having an explicit type annotation can improve readability, places where it harms readability, places where it doesn’t make much difference one way or another. Giving us the option has been a blessing. All programming calls for good taste, C++ programming calls for it more than most.
BeetleB 2y ago
> but it really does reduce code readability. How about not specifying the type, and letting the compiler infer it correctly and error out when it cannot - like so many other languages do? And those languages are much stricter about types than C++. And auto reducing code readability? Having to figure out the intricacies of a detailed type to write was a huge barrier, and virtually anyone reading the code with a type involving several nested angle brackets would not bother mentally parsing it anyway.
- Leherenn 2y ago
  I think it does reduce readability in some scenarios. For instance: const auto& processes = getCurrentlyRunningProcesses(); for (const auto& process: processes) { // Ok, what do I do with process now? Is it a pair from a map? A struct from a vector? // If it's a pair from a map, is the key the pid, a unique id, something else? } std::unordered_map<Pid, ProcessData> is more readable than auto here IMO: you don't need to open the definition (or hope your IDE correctly display the type).
deleted 2y ago
[deleted]
jamesfinlayson 2y ago
I remember reading something here recently about auto causing some painful and difficult to diagnose bug - I think string was what they thought the type should be (and some implicit cast would have made it a string if the type was specified)... but instead it created a string_view which went on to be used somewhere that accepted both string and string_view and then something tried to use it later but whatever the string_view was pointing to was gone (or something in that vein - I don't recall exactly).
- xonre 2y ago
  It's probably auto when you wanted auto&. A copy was made instead of a reference. I've been bitten by that.
ansgri 2y ago
Auto is an improvement for C++ only because of its uniquely unergonomic type system and standard library. I'd very much prefer writing something like `iterator<auto>` instead of `auto` or `std::map<lotsofchars>::iterator` and not be told by every linter to change most explicit type declarations to `auto`.

wk_end 2y ago

A verbose enough type - and C++ has plenty of those - is indistinguishable from line noise. There are places where having an explicit type annotation can improve readability, places where it harms readability, places where it doesn’t make much difference one way or another. Giving us the option has been a blessing. All programming calls for good taste, C++ programming calls for it more than most.

BeetleB 2y ago

> but it really does reduce code readability. How about not specifying the type, and letting the compiler infer it correctly and error out when it cannot - like so many other languages do? And those languages are much stricter about types than C++. And auto reducing code readability? Having to figure out the intricacies of a detailed type to write was a huge barrier, and virtually anyone reading the code with a type involving several nested angle brackets would not bother mentally parsing it anyway.

Leherenn 2y ago
I think it does reduce readability in some scenarios. For instance: const auto& processes = getCurrentlyRunningProcesses(); for (const auto& process: processes) { // Ok, what do I do with process now? Is it a pair from a map? A struct from a vector? // If it's a pair from a map, is the key the pid, a unique id, something else? } std::unordered_map<Pid, ProcessData> is more readable than auto here IMO: you don't need to open the definition (or hope your IDE correctly display the type).

deleted 2y ago

[deleted]

jamesfinlayson 2y ago

I remember reading something here recently about auto causing some painful and difficult to diagnose bug - I think string was what they thought the type should be (and some implicit cast would have made it a string if the type was specified)... but instead it created a string_view which went on to be used somewhere that accepted both string and string_view and then something tried to use it later but whatever the string_view was pointing to was gone (or something in that vein - I don't recall exactly).

xonre 2y ago
It's probably auto when you wanted auto&. A copy was made instead of a reference. I've been bitten by that.

ansgri 2y ago

Auto is an improvement for C++ only because of its uniquely unergonomic type system and standard library. I'd very much prefer writing something like `iterator<auto>` instead of `auto` or `std::map<lotsofchars>::iterator` and not be told by every linter to change most explicit type declarations to `auto`.