On Monday, May 19, 2025 9:11:47 PM Mountain Daylight Time Steven Schveighoffer via Digitalmars-d wrote:
> So why not just flag all unsigned/signed conversions? The problem with this idea (and technically it is a sound idea) is that it will flag so many things that are likely fine. Flagging all conversions just is going to be extremely noisy, and require casts everywhere. Subtraction is where the problems are.
>
> In cases where the compiler knows that unsigned subtraction won't wrap, it can also skip the warning.
>
> Thoughts?

Personally, I think that we should abolish all warnings in general. So, I'm very much against adding more. If you have warnings, ultimately, you either get stuck with a list of warnings that you have to wade through to see if there's anything that actually needs to be fixed, or you're forced to "fix" them even when they're not broken. I very much do not want the compiler spitting out stuff that I have to ignore or "fix" just to shut it up. And the fact that we currently have -w makes it all that much worse, because it means that warnings can change the results for type introspection and thus actually change what a program does rather than just warn the programmer of a potential problem. But even with -w being removed (or changed to behave like -wi), I still think that it's a mistake for the compiler to have warnings. Sometimes, a warning will show an actual problem, but in general, it just adds more stuff that programmers have to "fix" to shut the compiler up. If a problem is truly bad enough that it merits telling the programmer about it, then we should be looking at a reasonable set of conditions which are clearly an error and should be treated that way.

So, if we can come up with a compiler error that unequivocally indicates bad logic that actually does need to be fixed, then I'm all for adding it, but I think that anything along the lines of a warning should be left to a linting tool.

And really, this particular issue comes from the general issues of implicit conversions between signed and unsigned. Such implicit conversions are sometimes useful, but they also easily cause bugs which can be hard to find. I do wonder if we'd be better off if we just treated converting between signed and unsigned as the narrowing conversion that it is, or whether it would just create a need for too many casts. VRP would help, but it's not very sophisticated, so I don't know if it would help enough to matter. I suspect that with my code at least, making it an error would be absolutely fine, but it's likely to be very dependent on the kind of code that's written. Either way, from what I recall, Walter is very much against treating converting signedness as a narrowing conversion (even thouhgh it is), so I doubt that he'd agree to it.

- Jonathan M Davis

Counter proposal: throw data flow analysis at it, rather than change the language.

It would be able to catch things like:

```d
int[] array = [1, 2];
size_t offset;

foreach(i; 0 .. array.length) {
	offset = i + 1;
}

array[offset]; // Error out of bounds!
```

But not:

```d
void func(int[] array, size_t offset) {
	array[offset];
}
```

To catch the second would require false positives to be acceptable, and the default pain tolerance for the D community is lower.

Yes this is more complex to implement than a language change, but the support can be improved over time, it isn't fixed, and we can have the slower DFA that will error out in the latter example.

This is a common issue. Unfortunately, nobody has come up with a solution to this in the last 45 years. Since every combination of signed and unsigned has well-defined behavior, prohibiting one of those behaviors is going to break a lot of code. Changing the conversion rules will break a lot of existing behavior. There's no way around it.

There is hope, however. Try the following rules:

1. use `size_t` for all indices and pointer offsets

2. use `ptrdiff_t` for all deltas of the form `size_t - size_t`

Given:
```d
float vpos = 600 - 30 * (messages.length - i);
```
the types are:

```
float = int - int * (size_t - size_t);
```
The rvalue integral promotion rules turn everything into size_t, which is unsigned.

The difficulty arises from `(messages.length - i)` which is computing a delta between two `size_t`s being another `size_t`. What you'd like is the result of the expression being a `ptrdiff_t`.
```d
ptrdiff_t delta = messages.length - i;
float ypos = 600 - delta;
```
That should give you coherent and robust results. No forced cast is needed. (Forced casts should be avoided, as they can hide bugs.)

You could also do this:
```d
foreach_reverse(ptrdiff_t i, v; messages) // messages is a string array
{
    float vpos = 600 - 30 * i;
    DrawText(messages.ptr, 100, vpos.to!int, 20, Colors.WHITE);
}
```
but one could argue it's a bit too clever.

P.S. since size_t is just an alias for uint or ulong, a special status for size_t is impractical. So you cannot just say that `size_t - size_t` should be typed as `ptrdiff_t`.

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.

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