import std.stdio;
import std.meta;
void main()
{
    int nbad;
    foreach(T; AliasSeq!(short, ushort))
    {
        foreach(int i; T.min .. T.max + 1)
        {
            T x = cast(T)i;
            T y = ~x;
            T newy = cast(T)~cast(int)x;
            if(y != newy)
            {
                writefln("%s: x: %s, y: %s, newy: %s", T.stringof, x, y, newy);
                ++nbad;
            }
        }
    }
    writeln("Number of affected cases: ", nbad);
}

Output:

onlineapp.d(11): Deprecation: integral promotion not done for `~x`, use '-preview=intpromote' switch or `~cast(int)(x)`
onlineapp.d(11): Deprecation: integral promotion not done for `~x`, use '-preview=intpromote' switch or `~cast(int)(x)`
Number of affected cases: 0

Note that with -de these become errors. With the -preview=intpromote switch, the uncasted negation compiles and runs as expected.

Right now, the deprecation is telling users under penalty of not compiling to do something that will achieve nothing when intpromote is enabled.

-Steve

On Sunday, 12 September 2021 at 18:13:14 UTC, Walter Bright wrote:

But is this really ok to change variable size for simple bit flipping? maybe there should be exception at least for ~ operation?

void main()
{
    ushort a  = 0b100;
    ushort b  = ~a;
}

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

On 9/12/21 2:13 PM, Walter Bright wrote:

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:

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, 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

On 9/13/21 3:41 AM, Walter Bright wrote:

C allows exactly what he wrote, and it already works the same as it does in C.

-Steve

On Monday, 13 September 2021 at 11:41:29 UTC, Steven Schveighoffer wrote:

It could also help with finally turning it into an error and then making it the default. It's been almost 4 years now since the Pull Request introducing it was merged.

On 9/12/21 10:14 AM, Steven Schveighoffer wrote:

I thought I had tested this, but I must have been wrong. With -preview=intpromote, only the short version compiles, the ushort version complains that you can't fit an int into a ushort.

Which is unfortunate, because most people would not use bitwise negate on a short, they would do it on a ushort.

Still, I feel like D should allow what C allows here (and what currently working code expects).

-Steve