flagging unsigned subtraction assigned to bigger signed number?

[Steven Schveighoffer]

On Wednesday, 21 May 2025 at 04:44:35 UTC, Walter Bright wrote:
> This is a common issue. Unfortunately, nobody has come up with 
> a solution to this in the last 45 years.

Well, that doesn't mean we shouldn't try. AFAIK, the `if(cond);` 
issue existed for decades before we fixed it as well.

> Since every combination of signed and unsigned has well-defined 
> behavior, prohibiting one of those behaviors is going to break 
> a lot of code.

How much code? Is it worth it? Won't it find bugs in existing 
code that are dormant?

> Changing the conversion rules will break a lot of existing 
> behavior. There's no way around it.

I don't want to change any existing conversion rules. I want to 
flag likely error prone behavior. Like `if(cond);`.

> There is hope, however. Try the following rules:

This completely misses the point. There are solutions, obviously. 
An inexperienced programmer is going to run headlong into this 
wall and spend hours/days dealing with the fallout.

What I want is for the compiler to tell me when I likely got it 
wrong.

The errors of `if(a = b)` and `if(cond);` have been a godsend for 
me. Every time I hit that error, I thank the D gods that I was 
just saved an hour of head scratching. And I have 30 years 
experience developing software!

> P.P.S. Some languages, like Java, decided the solution is to 
> not have an unsigned type. This worked until programmers 
> resorted to desperate measures to fake an unsigned type.

This is not as dramatic as you make it sound. I think it was the 
correct decision.

But obviously, we can't go that route now.

> P.P.P.S. Forced casting results in hidden risk of losing 
> significant bits. Not a good plan for robust code.

Use `to` instead of `cast` if you are worried about losing bits. 
Which should be just about never. C developers get through life 
just fine, and lose bits left and right.

-Steve