3 ms·

Another reason for C/C++ is that they are very permissive with implicit lossy conversions. If you specified explicit type, chances are the compiler helpfully ma

Another reason for C/C++ is that they are very permissive with implicit lossy conversions. If you specified explicit type, chances are the compiler helpfully made a lossy conversion for you.

jfkebwjsbx 7y ago
If you use only explicit constructors and ban cast operators except for the most basic of types, then you have a sane language and explicitness in your code.
- MaxBarraclough 7y ago
  Sounds sensible. Google seems to agree with you. https://google.github.io/styleguide/cppguide.html#Implicit_Conversions https://google.github.io/styleguide/cppguide.html#Implicit_C... LLVM's coding standard though doesn't seem to have anything to say about implicit conversions: https://llvm.org/docs/CodingStandards.html https://llvm.org/docs/CodingStandards.html
- GoblinSlayer 7y ago
  It's sane on C++ scale, but on absolute scale that sanity is still wanting, Sutter mentions this.
MaxBarraclough 7y ago
Sutter made that point under Maintainability and robustness. Like Sutter's answer, this point doesn't answer the complaint. People on the anti-auto side say it seriously harms readability, as locals' types are no longer clear at a glance. They aren't asking for a list of reasons why some people favour auto, they're asking for an answer to their readability problem. Perhaps IDEs could infer types and display them as a superscript. That would keep just about everyone happy. (Perhaps not Vim users.)
- skocznymroczny 7y ago
  In IDE-friendly languages like Kotlin, you can enable showing of inferred types, e.g. https://i.stack.imgur.com/tiqjc.png https://i.stack.imgur.com/tiqjc.png
  - MaxBarraclough 7y ago
    Perfect, just what I was thinking. Does something like that exist for C++? Visual Studio 2019 doesn't seem to have it, but it's able to show a local's type when I hover over the local's identifier.
- GoblinSlayer 7y ago
  Herb didn't say it well enough. It's a tradeoff between correctness and readability. If it wasn't for C++'s weak type system you wouldn't be required to make this tradeoff and could improve readability while still staying correct.

Another reason for C/C++ is that they are very permissive with implicit lossy conversions. If you specified explicit type, chances are the compiler helpfully made a lossy conversion for you.

jfkebwjsbx 7y ago

If you use only explicit constructors and ban cast operators except for the most basic of types, then you have a sane language and explicitness in your code.

MaxBarraclough 7y ago
Sounds sensible. Google seems to agree with you. https://google.github.io/styleguide/cppguide.html#Implicit_Conversions https://google.github.io/styleguide/cppguide.html#Implicit_C... LLVM's coding standard though doesn't seem to have anything to say about implicit conversions: https://llvm.org/docs/CodingStandards.html https://llvm.org/docs/CodingStandards.html
GoblinSlayer 7y ago
It's sane on C++ scale, but on absolute scale that sanity is still wanting, Sutter mentions this.

MaxBarraclough 7y ago

Sutter made that point under Maintainability and robustness. Like Sutter's answer, this point doesn't answer the complaint. People on the anti-auto side say it seriously harms readability, as locals' types are no longer clear at a glance. They aren't asking for a list of reasons why some people favour auto, they're asking for an answer to their readability problem. Perhaps IDEs could infer types and display them as a superscript. That would keep just about everyone happy. (Perhaps not Vim users.)

skocznymroczny 7y ago
In IDE-friendly languages like Kotlin, you can enable showing of inferred types, e.g. https://i.stack.imgur.com/tiqjc.png https://i.stack.imgur.com/tiqjc.png
- MaxBarraclough 7y ago
  Perfect, just what I was thinking. Does something like that exist for C++? Visual Studio 2019 doesn't seem to have it, but it's able to show a local's type when I hover over the local's identifier.
GoblinSlayer 7y ago
Herb didn't say it well enough. It's a tradeoff between correctness and readability. If it wasn't for C++'s weak type system you wouldn't be required to make this tradeoff and could improve readability while still staying correct.