peer type resolution not coercing properly

[nektro]

Zig Version

0.10.0-dev.3672+cd5a9ba1f

Steps to Reproduce

const std = @import("std");

test {
    var a: u32 = 45;
    _ = &a;
    var b: u8 = 4;
    _ = &b;

    var runtime = true;
    _ = &runtime;
    var other = false;
    _ = &other;

    const x = if (runtime) blk: {
        break :blk a;
    } else if (other) blk: {
        break :blk b;
    } else null;

    try std.testing.expectEqual(?u32, @TypeOf(x));
    // try std.testing.expect(x == 45); // see #12609
}

Expected Behavior

All 1 tests passed.

Actual Behavior

test.zig:14:15: error: expected type '?u32', found '?u8'
    const x = if (runtime) blk: {
              ^~
test.zig:14:15: note: optional type child 'u8' cannot cast into optional type child 'u32'

[andrewrk]

I understand that this made it into stage1 however allowing such comparison is problematic and I think self-hosted behavior is better.

[nektro]

removed stage2 from title since stage1 fails too

./test.zig:10:15: error: incompatible types: 'u32' and '?u8'
    const x = if (runtime) blk: {
              ^
./test.zig:11:20: note: type 'u32' here
        break :blk a;
                   ^
./test.zig:10:15: note: type '?u8' here
    const x = if (runtime) blk: {
              ^

[mlugg]

There are two ways this snippet could be expected to work.

The first is if a chain of if / else if / else all did PTR and coercion as a single operation. That way, the resolved type would be ?u32, and all operands can coerce to that. I think this would be a quite reasonable change: it's effectively just order independence in the type resolution of such a chain.

The second, and arguably simpler one, is if we allow the coercion ?u8 -> ?u32 (more generally, ?A -> ?B if A coerces to B). As of my PTR rewrite, the snippet resolves the final type of ?u32 correctly, however it fails to perform the coercion, as the second if (i.e. from the else if to the else) coerces its result to a ?u8, and that can't coerce to the final resolved type of ?u32. If this were allowed, the snippet would work.

@andrewrk, I'm curious to hear why you thought this behavior was problematic. All it's really asking for is order-independence in type resolution of an if chain, which seems to me very reasonable, even if I understand why it doesn't currently happen.

[mlugg]

The solutions I listed above are proposed as #20627 and #16765 respectively. This proposal is not actionable in isolation so is closed in favour of those.