Why does intpromote spew warnings for ~ operator?

[Steven Schveighoffer]

On 9/12/21 2:13 PM, Walter Bright wrote:
> On 9/12/2021 7:14 AM, Steven Schveighoffer wrote:
>> Right now, the deprecation is telling users *under penalty of not 
>> compiling* to do something that will achieve nothing when intpromote 
>> is enabled.
> 
> The question for ~x is to promote x to an int and then complement, or 
> complement and then promote.. Those are not equivalent.
> 
> The idea is to move towards doing it the C way, which is promote and 
> then complement.
> 

I'm fine with the C way, I'm fine with what intpromote is trying to 
accomplish.

Yet, maybe you didn't understand what my point is.

This code:

```d
short s = 5;
short t = ~s;
writeln("t is ", t);
```

Compile without -preview=intpromote, you get the output:

```
onlineapp.d(6): Deprecation: integral promotion not done for `~s`, use 
'-preview=intpromote' switch or `~cast(int)(s)`
t is -6
```

Compile with -preview=intpromote, you get the output:

```
t is -6
```

In other words, the deprecation is suggesting I do something that is 
unnecessary. That's a terrible message to send.

Now, in my original rant, I erred in saying that ushort also works like 
this -- it doesn't. ushort requires a cast because 
`~cast(int)someUshort` is not going to fit into a ushort. I could have 
sworn I tested this, but it definitely fails without the cast.

However, the larger point, which I talked about [last 
year](https://forum.dlang.org/post/rn6hk1$1gii$1@digitalmars.com), is 
that anyone who has this code is going to be super-annoyed that they 
have to insert casts. If they want to get rid of the deprecation they 
need to insert *two* casts, one which can be removed after adding 
intpromote. But the point is that if you are assigning a small int to 
the result of another small int negation or complement, the intpromote 
rules don't fix anything. They just get in the way.

But this time, I'll just focus on the ~short, (and ~byte) which should 
be assignable to its own type, regardless of whether you promote first 
or not.

I think we can have a solution that allows code that behaves the same to 
continue to compile without deprecation, while deprecating the code that 
will change with -preview=intpromote.

-Steve