Deprecate implicit conversion between signed and unsigned integers

[Nick Treleaven]

On Sunday, 12 May 2024 at 13:32:36 UTC, Paul Backus wrote:
> In D, they cause the additional problem of breaking value-range 
> propagation (VRP):
>
>     enum byte a = -1;
>     enum uint b = a; // Ok, but...
>     enum byte c = b; // Error - original value range has been 
> lost
>
> D would be a simpler, easier-to-use language if these implicit 
> conversions were removed. The first step to doing that is to 
> deprecate them.

Signed to unsigned should be deprecated (except where VRP can 
tell the source was not negative).

Unsigned to signed can preserve the value range when the signed 
type is bigger than the unsigned type, e.g.:

     extern ubyte x;
     short y = x; // OK, short.max >= ubyte.max
     byte z = x;  // Deprecate, byte.max < ubyte.max

These deprecations should be for the next edition of D.

> While this is a breaking change, migration of old code would be 
> very simple: simply insert an explicit `cast` to silence the 
> error and restore the original behavior.

`cast` can be bug-prone if the original type gets changed. It 
would be better to have druntime template functions `signed` and 
`unsigned` to do the casts with IFTI to avoid changing the size 
of the type.

> In many cases, migration could be performed automatically with 
> a tool that uses the DMD frontend as a library.

Can you give some examples?

> I believe this change would be received positively by existing 
> D programmers, since D's willingness to discard C and C++'s 
> mistakes is one of the things that draws programmers to D in 
> the first place.

Yes, implicit conversion to a type with incompatible value range 
is too bug-prone, D should prevent that. It is particularly 
galling that decent C compilers have had warnings for this for 
such a long time.

What about comparisons between incompatible signed and unsigned, 
deprecate too?