Why does intpromote spew warnings for ~ operator?
Steven Schveighoffer
schveiguy at gmail.com
Mon Sep 13 11:41:29 UTC 2021
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
More information about the Digitalmars-d
mailing list