Annoyance with new integer promotion deprecations

[Steven Schveighoffer]

On 2/5/18 2:22 PM, H. S. Teoh wrote:
> Code:
> 
> 	struct S {
> 		byte[2] x;
> 	}
> 	void main() {
> 		S s, t;
> 		s.x = [ 1, -1 ];		// OK
> 		t.x = [ -s.x[0], -s.x[1] ];	// NG (line 7)
> 	}
> 
> 
> Compiler says:
> 	/tmp/test.d(7): Deprecation: integral promotion not done for `-s.x[0]`, use '-transition=intpromote' switch or `-cast(int)(s.x[0])`
> 	/tmp/test.d(7): Deprecation: integral promotion not done for `-s.x[1]`, use '-transition=intpromote' switch or `-cast(int)(s.x[1])`
> 
> 
> Why should I need to explicitly cast to int only to reassign it back to
> byte?!  This is ridiculous.

Note, it's just a deprecation message, and not an error. So actually, 
your code is compiling just the way it did before the rules (in fact, 
the rules are only implemented if you use the -transition=intpromote 
switch).

In the future, the compiler is going to promote s.x[0] to an int before 
applying the negation. This makes a difference when the byte is byte.min:

byte b = byte.min;
int x = -b;

assert(x == -128) // without -transition=intpromote
assert(x == 128) // with -transition=intpromote (also is the behavior of 
C++)

IMO, you shouldn't have to cast to int first, if you are just casting 
back to byte:

int x = cast(byte)-b;

assert(x == -128) // both with and without intpromote

But I don't know if the compiler can be made to see this eventual result 
and not output the deprecation. Either way, the deprecation is still not 
a full error.

In the future, your line initializing t will fail (can't implicitly cast 
int to byte), so you will eventually need a byte cast at least.

-Steve