Open nektro opened 2 years ago
I understand that this made it into stage1 however allowing such comparison is problematic and I think self-hosted behavior is better.
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: {
^
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.
Zig Version
0.10.0-dev.3672+cd5a9ba1f
Steps to Reproduce
Expected Behavior
Actual Behavior