New integer promotion rules

[ag0aep6g]

On 01/17/2018 11:30 PM, rumbu wrote:
> 1. Why do I need explicitely to promote my byte to int in order to 
> assign it to an ulong?
> 2.077: ulong u = -b; 2.088: ulong u = -cast(int)b;

Those two snippets are not equivalent.

When b = byte.min, the 2.077 snippet gives u = 18446744073709551488, 
while the 2.078 snippet gives u = 128 even when compiled with 2.077.

Old code may rely on u = 18446744073709551488, and that's why dmd 2.078 
doesn't just silently give you 128. Instead you have to use the cast or 
the compiler switch to tell dmd that you actually want the new behavior. 
In the future, the new behavior is going to become the default.

You have to be explicit about this so that dmd doesn't break your code 
without you noticing.

> 2. Why do I need a cast(int) to assign a byte to an ubyte, since I'm 
> explicitely cast it?
> 2.077: ubyte c = cast(ubyte)-b; 2.088: ubyte c = cast(ubyte)-cast(int)b

As above, when b = byte(-128), then `-b` is going to change from 
byte(-128) to int(128). In this case, that doesn't affect the result, 
because `cast(ubyte) byte(-128)` and `cast(ubyte) int(128)` are both 
128. But the compiler obviously doesn't look that far. And it's not 
possible for the compiler to analyse the whole program before giving you 
the deprecation message.