Deprecate implicit conversion between signed and unsigned integers

[Quirin Schroll]

On Monday, 17 February 2025 at 09:01:45 UTC, Walter Bright wrote:
> On 2/13/2025 4:00 PM, Quirin Schroll wrote:
>> Signed and unsigned multiplication, division and modulo are 
>> completely different operations.
>
> Signed and unsigned multiplication produce the exact same bit 
> pattern result. Division and modulo are indeed different.

You’re right, I was mistaken. I thought multiplication by −1 had 
to be different than multiplication my `T.max`, but it’s not.

>> None of those are a bad choice; tradeoffs everywhere.
>
> It's always tradeoffs.

Sometimes, there are better things.

>>> 4. What happens with `p[i]`? If `p` is the beginning of a 
>>> memory object, we want `i` to be unsigned. If `p` points to 
>>> the middle, we want `i` to be signed. What should be the type 
>>> of `p - q`? signed or unsigned?
>> 
>> Two questions, two answers.
>> 
>>> What happens with `p[i]`?
>> 
>> That’s a vague question. If `p` is a slice, range error if `i` 
>> is signed and negative. If `p` is a pointer, it’s `*(p + i)` 
>> and if `i` is signed and negative, so be it. `typeof(p + i)` 
>> is `typeof(p)`, so there shouldn’t be a problem.
>
> Sorry, I meant `p` as a pointer. I use `a` as an array (or 
> slice). A pointer can move forward or backwards, so the index 
> is signed. A slice cannot back up, so the index is unsigned. A 
> slice can be converted to a pointer. So then what, is the index 
> signed or unsigned? There's no answer for that.

The index already has a type. The operation `p + i` can support 
signed and unsigned `i` via overloading. I really don’t see the 
problem. You’re not inferring the type of the index because of 
the operation.

>>> What should be the type of `p - q`? signed or unsigned?
>> 
>> Signed.
>
> That doesn't work if the array is bigger than the int range, or 
> happens to straddle `int.max`. (The garbage collector can run 
> into this.)

Why would the GC use `int`? Unless, of course, it happens to 
equal `ptrdiff_t`? Those are conceptually different.

The general problem is, basically, that differences of n-bit 
integers require n+1 bits to represent. That problem is not 
inherent to unsigned values, it’s just more obvious because 2 − 1 
can’t be represented. In signed world, `-2` − `int.max` doesn’t 
fit in an `int` either. Making them signed doesn’t fix 
differences of indices totally, only differences of non-negative 
values.

>> While it would be annoying for sure, it does make sense to use 
>> a function for pointer subtraction when one assumes the 
>> difference to be positive: `unsignedDifference(p, q)` It would 
>> assert that the result is in fact positive or zero and return 
>> a `size_t`. The cool thing about it is that if you expect an 
>> unsigned result and happen to be wrong, you’ll find out 
>> quicker than otherwise.
>
> I'm sorry, all these extra baggage and rules about signed and 
> unsigned makes it harder to use, not easier.

It’s much harder to write bugs when signed and unsigned are 
separated.

>> As I see it, 2’s complement for both signed and unsigned 
>> arithmetic is a straightforward choice D made to keep `@safe` 
>> useful.
>
> D's type system preceded @safe by many years :-/

My argument isn’t so much about history, but UB. Java does the 
same.

>> If D made any of them UB, it would exclude part of basic 
>> arithmetic from `@safe` because `@safe` bans every operation 
>> that *can* introduce UB.
>
> @safe only bans memory corruption.

In the language design space, there’s no difference between UB 
and memory corruption because memory corruption is a form of UB 
and any UB can lead to memory corruption (by definition really). 
Therefore, speaking about memory corruption is equivalent to 
speaking about UB generally.

D’s `@safe` bans all UB (by intent at least). If it didn’t, it 
would allow for memory corruption; it doesn’t matter if it’s 
directly or indirectly.

> 2's complement arithmetic is not UB.

Of course it’s not. The alternative to 2’s complement is UB 
(practically speaking). There are some odd platforms with a 
negative representation that’s not 2’s complement, but D supports 
none of them.

What I’m saying is, when designing a programming language, your 
choices to integer overflow are: 2’s complement or UB. D chose 
2’s complement overall (also Java), C/C++ chose 2’s complement 
for unsigned and UB for signed, Zig chose UB overall.

Guaranteeing 2’s complement means the operation is well-defined 
for all inputs, but the optimizer can do less. Tradeoffs 
everywhere.

Even before `@safe`, having all operations on integers 
well-defined (maybe ignore division by zero) has positives that I 
guess you saw.

Historically speaking, had D taken the C/C++ or Zig route, there 
would be no `@safe` because if basic operations on integers can 
be UB, adding a feature like `@safe` makes no sense.

>> It’s essentially why pointer arithmetic is banned in `@safe`, 
>> since `++p` might push `p` outside an array, which is UB. D 
>> offers slices as a safe (because checked) alternative to 
>> pointers.
>
> `--p` and `++p` are always unsafe whether the implicit 
> conversions are there or not.

What I find interesting is that:
- For pointers, it’s obvious to almost anyone that slices are a 
win because of bounds checking, even though it comes with a dual 
cost: The length has to be stored and indexing operations have to 
range-checked.
- For integer operations, people seem to be hesitant to 
range-check them, even though that comes only with the cost of 
doing the check; no bound has to be stored.

It’s not that 2’s complement doesn’t have its place; what I am 
saying is: The language constructs should be as close to the 
intuition of the programmer as possible. I for once know when I’m 
making deliberate use of the bit representation of integers, 
however, without checks, I’m making use of the bit representation 
of integers with every operation, most of the time when I don’t 
intend to.

Most of the time, the fact that integers are binary is 
conceptually irrelevant.

>>> 6. Casts are a blunt instrument that impair readability and 
>>> can cause unexpected behavior when changing a type in a 
>>> refactoring. High quality code avoids the use of explicit 
>>> casts as much as possible.
>> 
>> In my experience, when signed and unsigned are mixed, it 
>> points to a design issue.
>> I had this experience a couple of times working on an older 
>> C++ codebase.
>
> Hence my suggestions.

One cannot apply suggestions retroactively to a huge codebase 
that’s >15 years old.

One can, however, ban narrowing conversions and discover the 
problematic spots in compile errors and address them properly.

> I look at it this way. D is a systems programming language. A 
> requirement for being successful at it is understanding 2's 
> complement arithmetic, including what wraparound is.

While I agree that it is true and that I would exclude anyone 
from being called a competent programmer who doesn’t understand 
2’s complement, I find myself rarely thinking about indices and 
whatnot something other than an integer with a limited range. For 
hashing and some other algorithms, you do think of those as 
elements of an ordered [unitary 
ring](https://en.wikipedia.org/wiki/Ring_(mathematics)) with an 
operation referred to as “division with remainder.”

D inherited its types from C and C inherited them from the 
operations of machines. It wouldn’t have occurred to the creators 
of C to provide different types for doing boolean logic, integer 
arithmetic, indexing arithmetic a.k.a. addressing, and bit 
operations. All of these happen in the same kinds of registers; 
to most people, however, a boolean value isn’t an integer (even C 
added `_Bool` and then `bool`); a number isn’t an index, and an 
index isn’t a bit-vector. To most people, `size_t` means more 
than “alias to the bit-width unsigned integer type the same size 
as addresses,” but conceptualizes sizes of memory or indices into 
arrays (in memory). Nobody would use a `size_t` to model the age 
of something; age is a number (within some range) and not an 
index.

What’s the difference between `i << 1` and `i * 2`? From the 
low-level perspective, literally none after optimization. 
However, in code, those encode very different intents.

D is a low-level _and_ a high-level language. From the higher 
levels, mixing bit-vectors and numbers is usually a mistake. The 
language requiring to state that, yes, that’s indeed what you 
want isn’t exactly bad.

> It's not that dissimilar to the requirement of some 
> understanding of how floating point code works and its 
> limitations, otherwise grief will be your inevitable companion.
>
> Also that a `bool` is a one bit integer arithmetic type.

I wonder why D has an 1-bit integer type which is conceptually a 
boolean value, but no general n-bit integer types? C23 added 
`_BitInt(n)` and `_BitInt(1)` is not `bool` (which C23 made a 
proper type).

> I know there are languages that attempt to hide all this stuff, 
> but D isn't one of them.

There’s a difference between hiding and not needlessly exposing.

Making the implicit conversion of `int` to and from `uint` an 
error isn’t hiding things akin to Java hiding its pointers.

Narrowing implicit conversions warrant a warning in C and C++ and 
rightly so – it is likely a mistake and a local fix is available 
(use an explicit cast); brace-initialization in C++ outright bans 
it. By the design of D, it should be an error. Alternatives are:
- Redesign so the error doesn’t even come up anymore.
- Assert, then cast. (If you’re “really sure” it can’t fail.)
- Use a throwing narrowing conversion function. (If you’re 
“mostly sure” it can’t fail.)