https://shafik.github.io/c++/2021/12/30/usual_arithmetic_confusions.html

Unfortunately, this is also one of the areas of D that comes directly from C, so D programmers have to watch out for these as well.

It's been argued in the past, on these forums, that these conversions are "just something you have to learn" if you want to do system-level programming. But if C++ programmers are still getting this stuff wrong, after all these years, perhaps the programmers aren't the problem. Is it possible that these implicit conversions are just too inherently error-prone for programmers to reliably use correctly?

On Friday, 28 January 2022 at 03:46:00 UTC, forkit wrote:

Nit: I think it should be -vimplicit-conversions, as the other diagnostic switches start with -v (-vtls, -vtemplates, -vgc, etc). You can see the docs here:

https://dlang.org/dmd-linux.html

On Friday, 28 January 2022 at 02:15:51 UTC, Paul Backus wrote:

Not surprisingly, the system programming languages outside C family tend to go with explicit conversions.

On Friday, 28 January 2022 at 02:15:51 UTC, Paul Backus wrote:

For what it is worth, the first exemple is fixed in D.

The multiplication one is particularly interesting. The other ones really banal wrap around behavior, which your really can't do without if youw ant to make anything fast, IMO.

I'm surprised there aren't more exemple of signed -> unsigned conversion because that one is a real mind fuck.

On Friday, 28 January 2022 at 18:39:54 UTC, deadalnix wrote:

Modern programing languages tend to have separate operators or intrinsincs for wrapped and non-wrapped (trap on overflow) arithmetic operations. In the vast majority of cases having an arithmetic overflow is a bug in the code. And being able to catch such bugs is as useful as having bounds checking for arrays. I think that it's only a matter of time until processors start adding the missing instructions to make this fast. That's a typical chicken/egg problem. If Rust language becomes really popular, then the hardware will adapt.

On Friday, 28 January 2022 at 18:39:54 UTC, deadalnix wrote:

For C++ this is fixed with warnings, e.g. -Wconversion

People can choose their own level of strictness in C++. Of course, if you use templated libraries then you might get warnings you don't want. So having a good syntax for silencing warnings inline is an important language design issue, because then you are encouraged to turn on maximum strictness and just selectively disable it where it is convenient.

Warnings with inline-silencing is actually one of the main advantages of using TypeScript over javascript and Python with PyCharm as well.

Unfortunately the syntax for warning silencing is often just an afterthought... It should be part of language-design in my opinion.

I actually can't remember having these issues in my own code, it isn't really all that difficult to get these right. But you have to pay special attention to these things when writing templates, fortunately you can restrict templated parameters based on signedness.

The only case that I can remember where this turned into a headache was with signed modulo operator, but it was resolved by writing my own overloaded "modulo(x,y)" function.

Of course, if you don't enable warnings you've basically said you are ok with the semantics of a lazy 1970s approach designed to make it possible to write really terse code. People get what they ask for by choosing terseness.