Bitwise complement should propagate result type

[matklad]

Zig Version

0.14.0

Steps to Reproduce and Observed Behavior

λ cat main.zig
const std = @import("std");
const assert = std.debug.assert;

pub fn main() void {
    const x: u64 = ~0;
    assert(x == std.math.maxInt(u64));
}
matklad@TigerMac ~/p/tb/work (matklad/fix-assert *)
λ ~/zig-0.14/zig run main.zig
main.zig:5:20: error: unable to perform binary not operation on type 'comptime_int'
    const x: u64 = ~0;

Expected Behavior

Program exists with zero.

[matklad]

I think in const x: u64 = ~0; compiler should see that the result is u64, and so 0 must be typed as u64, not as comptime_int.

I think this is not just pedantry, as ~0 is a useful idiom:

• it's shorter than std.math.maxInt(u64)
• it avoids naming the type, preventing bugs when the type changes (const x: u128 = std.math.maxInt(u64))

[mlugg]

This is a proposal, but certainly a very reasonable one. It's quite similar to #16489.

The reason why this isn't quite a no-brainer "enhancement" is because it is subtly breaking:

const x: u8 = 0b1111_1111;
/// On `master`, this works: the complement gives `@as(u8, 0)`, and that is then coerced to `u1`.
/// But if we implement this proposal, it is a compile error, because `x` is not a valid `u1`.
/// This is just like the first potential breakage listed in #16489.
const y: u1 = ~x;

[IntegratedQuantum]

This could also fix a rather subtle class of bugs I often ran into, when masking off the least significant bits:

const size: u31 = 1 << ...;
const mask = size - 1;
...
var x: i32 = ...
x &= ~mask; // oops, now it breaks for negative numbers