In Rust what they'd do if they realised there's a problem like this is make explicit conversion the default, with a language Edition, and so within a few years just everybody is used to the improved language. In C++ instead you have to learn to write all the appropriate bugfix keywords all over your software, forever.
Agreed. The history here is compatibility with C type conversion.
I just expected a more compelling Rust /C++ comparison but we got an emphasis of a poorly designed feature which the standard has taken steps to improve already.
In C++ when we define a class Foo (a thing which doesn't exist in C) and we write a constructor Foo(Bar x) (which doesn't exist in C) which takes a single parameter [in this case a Bar named x], that is implicitly adopted as a conversion for your new user defined type and by default without any action on your part the compiler will just invoke that constructor to make a Bar into a Foo whenever it thinks that would compile.
This is a bad choice, and it's not a C choice, it's not about "compatibility".
“Implicit arithmetic conversions work much as expected. In general, if an operator like + or * that takes two operands (a binary operator) has operands of different types, the ``lower'' typekis promoted to the ``higher'' type before the operation proceeds.”
It goes on including giving a table of all the conversions and a set of heuristics which normally apply.Numbers are implicitly converted to the “largest” and perhaps “floatiest” representation.