RLS for bitwise not operator `~`

[silversquirl]

This is a proposal to have the ~ operator propagate its result type to its operand.
My main motivation for proposing this is the following footgun:

const MyStruct = struct {
    x: u32,
};

// somewhere far away
const foo: MyStruct = .{ .x = ~@as(u32, 0) };
std.debug.assert(~foo.x == 0);

If the type of the x field is changed to u64, the assert will begin failing. In many cases, there is no such assert, and instead the code silently breaks in ways that may be difficult to detect.
Currently, to reliably get the desired behaviour, one must write code like this:

const foo: MyStruct = .{ .x = ~@as(@FieldType(MyStruct, "x"), 0) };

Which is pretty difficult to read. With the proposed change, the snippet could be written like this instead:

const foo: MyStruct = .{ .x = ~0 };

Breaking

This is unfortunately a breaking change, as illustrated by this example:

const x: u8 = 0;
const y: u16 = ~x;
// prior to this change, y == 0x00ff
// after this change, y == 0xffff

I personally think both of these behaviours are equally confusing, but at least with the proposed change you have all the type information you need in one place, and don't have to go look at the type of x.

[mlugg]

(Language proposal authorized by me.) I agree that this would be a nice change and that the breakage is at worst neutral.

[Nirlah]

The proposed behavior when ~ is applied to integer literals makes sense and improves ergonomics.

However, I believe extending the proposed behavior to variables would be incorrect.

Consider the example in the proposal when applied to a bitfield representing toggles. Under the proposed change, extending the bit width produces an undesired result:

const toggles: u8 = 0b00001011;
const more_toggles: u16 = ~toggles;

// Current behavior:
std.debug.assert(more_toggles == 0b0000000011110100);

// Proposed behavior:
std.debug.assert(more_toggles == 0b1111111111110100);

While the proposal simplifies certain use cases, it introduces unwanted results in others.
Zig’s emphasizes clarity and correctness over brevity, so such scenarios should continue to use explicit semantics to avoid ambiguity.

I suggest limiting the scope of the proposal to using ~ only with integer literals values.

[npc1054657282]

This proposal proposes to extend result type propagation to the operands of arithmetic operators.
Currently, almost all arithmetic operators do not support result type propagation.
If there is an arithmetic operator whose operands support result type propagation, I would definitely expect all arithmetic operators to support result type propagation, otherwise this inconsistency would confuse me.

E.g., if the bitwise negation operator supported result type propagation, then I would also expect the following behavior:

    const a: u8 = 255;
    const b: u8 = 255;
    var c: u32 = a +% b;
    try std.testing.expectEqual(510, c); // This is wrong in the current version

Considering that this behavior may also lead to misuse, I think the solution based on this is to disallow arithmetic operands' types differ from their result types.

If the type of the x field is changed to u64, the assert will begin failing. In many cases, there is no such assert, and instead the code silently breaks in ways that may be difficult to detect.

I believe that simply disallowing implicit conversions to the result type and enforcing that the operand types be the same as the result type would solve this problem.

We can keep the following code unchanged:

const MyStruct = struct {
    x: u32,
};

// somewhere far away
const foo: MyStruct = .{ .x = ~@as(u32, 0) };
std.debug.assert(~foo.x == 0);

If the type of the x field is changed to u64, this will result in a compilation error. The code must be modified to:

const MyStruct = struct {
    x: u64,
};

// somewhere far away
const foo: MyStruct = .{ .x = ~@as(u64, 0) };
std.debug.assert(~foo.x == 0);

[andrewrk]

I have two major problems with this proposal.

1. I don't agree with the problem statement. assert(~foo.x == 0); is a self-inflicted footgun either way. If the integer size changes, then it might change such that the expression is supposed to equal zero or not supposed to equal zero in order to maintain the same behavior. To avoid the footgun requires introducing more precision of intent with or without this proposal.

2. The breaking change that this makes is a nasty footgun. It's unintuitive for the result type to override the actual type of the operation. There's no way in hell someone who hasn't seen Zig code before is going to guess correctly that the u16 wins the fight over the u8 in this example.

Feel free to discuss further, but I'm going to close this because you'll have to convince me to depart quite far from my position on this for it to be seriously considered.