Common type of ubyte and const ubyte is int

[Steven Schveighoffer]

On Friday, 3 May 2024 at 06:52:00 UTC, Dom DiSc wrote:
> On Thursday, 2 May 2024 at 17:30:12 UTC, user1234 wrote:
>> Just remembered, one argument that was once exposed by Walter 
>> is be that arithmetic instructions for 32 bits registers would 
>> be faster than the ones let's say for 16 or 8.
>
> Working on the processor word size is always the fastest. But 
> that is totally independent of the result type. Calculation can 
> always be done extended to word-size (or may need multiple 
> words for large operands), but the result should have the 
> common type.
> To say 32bit is always the best is only true for 32bit 
> architectures.
> And having no promotion is not an option. If two operands are 
> to be combined, we need some common type for the result, no 
> matter how this result is produced.

This is all very interesting, but remember, there is no operation 
or calculation happening here. We have a construct that is 
picking an 8 bit unsigned value, or an 8 bit unsigned value, and 
it is resulting in a 32-bit signed value.

If this kind of thing requires integer promotion then the 
following should be true:

```d
ubyte x = 5;
auto y = x;
static assert(is(typeof(y) == int));
```

But that is not the case. I don't mean to be pedantic here, but 
this is the inconsistency I see in this part of the compiler.

>
> About type attributes - the operands may be mutable, const or 
> immutable, but the result is a new value with attributes 
> independent of the operand attributes. It should be assignable 
> to mutable variables - to const or immutable objects only 
> during initialization, to shared objects only if they are 
> locked.

Common type modifier differences can be tested with `int`, and I 
believe the rules are sound there.

-Steve