Annoyance with new integer promotion deprecations

[Walter Bright]

On 2/5/2018 4:08 PM, Steven Schveighoffer wrote:
> In fact, this works in C:
> 
> char a = 1;
> char b = 2;
> char c = a + b;
> 
> I would actually have no problem if it were this way, as you are clear in your 
> intention. I'm also OK with the way it is now, where it requires the cast. The 
> cast is generally added "because the compiler told me to", but it does make you 
> think about what you really want.

D worked that way initially, too. But people strongly complained that it was 
unintuitive and buggy.

 > clear in your intention

Except it wasn't. People did not expect truncation and had bugs.

The thing is, when there are mixed integer sizes and signedness, there is no 
intuitive and correct solution. Each set of rules comes with its own set of 
cases where there are unintuitive behaviors.

D picked a solution which followed the C rules so that debugged C code will not 
break when transferred to D. This is the correct solution for D. D modified that 
by requiring a cast any time truncation (i.e. losing bits) would happen. 
Although this did technically break C compatibility, there was a compile time 
error generated, so there was no silent breakage.

Changing the semantics would just break a lot of existing, working code in 
undetectable ways, and then introduce another set of unintuitive behaviors that 
a while down the pike will result in more of these threads.

There really isn't much one can do other than learn the integral promotion 
rules. They're only a couple of sentences. We can handle it. (And how 2's 
complement arithmetic works.)