Invalid pointer casts permitted by in-memory coercion to covariant types

[mlugg]

Zig Version

0.11.0-dev.3031+f40539e5d

Steps to Reproduce and Observed Behavior

pub fn main() void {
    var e: error{Foo} = error.Foo;
    const p: *error{ Foo, Bar } = &e;
    p.* = error.Bar;
    @import("std").log.info("{}", .{e});
}

Output:
info: error.Bar
This output should be impossible, since e is of type error{Foo} so should not be able to hold the value error.Bar.

Expected Behavior

A compile error should be triggered.

This happens because a pointer *T is allowed to coerce to a pointer *U whenever T is in-memory coercible to U. When the target pointer is not const, this is insufficient: it is also a requirement that U be in-memory coercible to T, so that writes to the pointer cannot assign invalid values to the destination.

[InKryption]

What's the use case for allowing coercions of this kind? Wouldn't it be simpler to just disallow coercing *T to *U if T and U are non-equivalent error sets?

[mlugg]

The practicality of this might be better-illustrated with an error union:

const x: error{Foo}!SomeReallyBigStruct = myFunction();
const p: *const error{ Foo, Bar }!SomeReallyBigStruct = &x;

The logic runs the exact same here - this is safe, but if you drop the const it allows Bad Things - but the reason you might want to do this is perhaps a little more clear. Also note that there might be a case other than errors where you can trigger this, since the in-memory coercion logic is fairly general - the other obvious thing was nullable vs non-nullable pointers, but it seems there's an existing special case to handle that. If error sets really are the only issue here, all we need is a similar special case; no need to unnecessarily limit the language.

I'm going to take a stab at this :)