Common type of ubyte and const ubyte is int

[Jonathan M Davis]

On Friday, May 3, 2024 1:40:36 PM MDT Walter Bright via Digitalmars-d wrote:
> On 5/1/2024 7:42 AM, Steven Schveighoffer wrote:
> > It seems rule 2 would apply instead of rule 6? but I don't like it.
>
> ```
> #include <stdio.h>
>
> void main()
> {
>      char u;
>      const char v;
>      printf("%ld %ld\n", sizeof(u), sizeof(1?u:v));
> }
> ```
>
> This prints "1 4". D follows the same integral promotion rules, and the
> reason is if one translates C code to D, one doesn't get an unpleasant
> hidden surprise.

Sure, but are there actually any unpleasant surprises if C code using the
ternary operator is converted to D? If you have

    uint8_t left;
    const uint8_t right;

    uint8_t result = cond ? left : right;

whether integer promotion occurs or not is irrelevant, because no arithmetic
is happening, and C will happily downcast an int to a uint8_t. So, whether
the ternary operator results in uint8_t or int doesn't affect the result at
all.

On the flip side, if you assign the result to an int,

    uint8_t left;
    const uint8_t right;

    int result = cond ? left : right;

whether integer promotion occurred is again irrelevant, because no
arithmetic is occurring, and both results will fit in an int whether the
ternary operator converted the result to int or left it as uint8_t.

And since char in C is the same as either uint8_t or int8_t depending on the
platform, using char in those two examples would have the same result.

So, as far as I can tell, the C code does not care whether integer promotion
occurs with the ternary operator or not. It would care if it had type
inference via something like D's auto, but it doesn't. The value of the
result is the same whether integer promotion occurs or not, and that's all
that C actually cares about unless you're doing something like sizeof on the
expression, which is not exactly a typical thing to be doing. And that's
probably why C++ was perfectly fine with changing the behavior. It doesn't
actually break code in practice.

This issue only comes up in D, because we have auto, and we make downcasting
with integer types illegal. So, promoting byte to int when no arithmetic is
actually occurring just because the other branch of the ternary used const
is highly surprising and increases the chances of code breakage due to
downcasting not being legal.

It's also pretty terrible for generic code, because with almost all types if
you have

    T left;
    const T right;

    auto result = cond ? left : right;

the result will be const T, whereas with smaller integer types, it would be
int, which almost no one will expect. And unless VRP kicks in

    T left;
    const T right;

    const T result = cond ? left : right;

will fail to compile for small integer types while it compiles for every
other type in the language.

So, from what I can tell, we're not going to break C code whether the
ternary operator does integer promotion or not, but it _does_ cause problems
for D code that integer promotion occurs even though there is no arithmetic
expression involved.

And on top of that, by changing D to not do integer promotion with the
ternary operator, we would be more compatible with C++ where the difference
_does_ matter, because they have their own auto, and they have function
overloading.

So, I don't see how sticking to the C behavior in this case helps at all,
and it clearly hurts us for both straight up D code and for porting C++ code
to D.

- Jonathan M Davis