error{} != error{}

[ghost]

Apparently, every time you use error{} as a generic type param, it creates a new unique type (incompatible with previous expressions of the same type).

This is probably "as designed" but I would still like to know for sure (the rules on how generic type identity works are somewhat mysterious to me). error{} is probably not the only case where it feels like it should work but doesn't.

fn Writer(comptime E: type) type {
    return struct {};
}

pub fn main() void {
    const writer: Writer(error{}) = Writer(error{}){};
}

./asdf.zig:6:52: error: expected type 'Writer(writer)', found 'Writer(error:6:26)'
    const writer: Writer(error{}) = Writer(error{}){};
                                                   ^
./asdf.zig:2:12: note: Writer(writer) declared here
    return struct {};
           ^
./asdf.zig:2:12: note: Writer(error:6:26) declared here
    return struct {};
           ^

Side note: the name it came up with, Writer(writer) is pretty strange.

I am aware of the workarounds:

    const Error = error{};
    const writer: Writer(Error) = Writer(Error){};
    // or
    const MyWriter = Writer(error{});
    const writer: MyWriter = MyWriter{};

[ikskuh]

I think the expected behaviour is that error{} == error{} should yield true. right now error types are compared as any other type, but i don' think that's the correct behaviour.

Error set types should be cached/hashed based on their content and have structural equality similar to integers.

This means that also error{A,B} == error{A}||error{B} shoud yield true which is not the case atm

[ghost]

Whoops, I didn't even think to try error{} == error{}. You're right that's the real issue here, I'll edit the issue title.

[g-w1]

My pr #7092 which implements error set merging in stage2 impliments this correctly. The following test currently passes:
https://github.com/ziglang/zig/pull/7092/files#diff-fe87a84eb6da1b5d2b6692aaf4c096531e480add4c2c7d381e32f9095f5a56e5R392-R398