Disallow error union with error set payload, E!E

[Vexu]

The type makes no sense and cannot be created:

test {
    const E = error{Foo};


    // error: expected type 'E', found 'error{Bar}'
    var a: E!anyerror = error.Bar;


    // error: expected type 'E', found 'anyerror'
    var b: anyerror = error.Bar;
    var a: E!anyerror = b;


    // panic: invalid error code
    var b: anyerror = error.Bar;
    var a: E!anyerror = @errSetCast(E, b);


    // panic: reached unreachable code
    @setRuntimeSafety(false);
    var b: anyerror = error.Bar;
    var a: E!anyerror = @errSetCast(E, b);
    var discard = a catch @import("std").debug.assert(false);
}

// This does work but hardly justifies its existence.
const E = error{Foo};
const E2 = error{Bar};
const S = struct { payload: E2, err: u16 };
test {
    var a: E!E2 = undefined;
    a = @bitCast(E!E2, S{ .payload = E2.Bar, .err = 0 });
    var foo = a catch unreachable;
}

[squeek502]

Alternatively, dealing with an error as a value could be made more explicit (or forced to be explicit whenever it is ambiguous). Example (basically pseudo-code, no idea how it would/could actually be implemented):

var a: E!anyerror = @errAsValue(error.Bar);
if (a) |_| {} else { unreachable; }

var b: E!anyerror = error.Bar;
if (b) |_| { unreachable; } else {}

Somewhat related: #5820

[daurnimator]

You should be able to create an error union with anything, adding an exception to the rule for error unions of error unions seems needless inconsistent.
I can imagine code such as:

const std = @import("std");

fn anything() !void {
    return error.Foo;
}

fn handle_result(E: anytype) !E {
    try std.io.getStdOut().writer().print("Some Log Message", .{});
    return E;
}

test "error union of error union" {
    try handle_result(anything());
}

Note that this currently segfaults in IR analysis :/

[Vexu]

This issue is about error unions with error set payloads, any generic code would need to have a special case for handling them since creating them would require some kind of @errorAsPayload builtin or a @bitCast hack.

Error unions with error union payloads already kind of work and can make sense in some situations like in the example you provided.

[daurnimator]

This issue is about error unions with error set payloads

ah.

any generic code would need to have a special case for handling them since creating them would require some kind of @errorAsPayload builtin or a @bitCast hack.

Howso?

What about:

fn whatistheerrorset(comptime a: i32) !type {
    switch (a) {
        0 => return error{Foo},
        1 => return error{Bar},
        2 => return error{ Foo, Bar },
        else => return error.InvalidCompileOption,
    }
}

test "error union of error set" {
    const someerrorset = try whatistheerrorset(1);
}

[Vexu]

That is an error union with a type payload and it works just fine, however if you were to do something like:

fn whatistheerrorset(comptime a: i32) error{InvalidCompileOption}!anyerror {
    switch (a) {
        0 => return error.Foo,
        1 => return error.Bar,
        else => return error.InvalidCompileOption,
    }
}

test "error union of error set" {
    const someerrorset = try whatistheerrorset(1);
}

How is the compiler supposed to know if you made a type error by returning error.Foo or if you meant to return it as the payload of an error union. This would be solved by doing something like @errorAsPayload(error.Foo) in which case it is clear that there was no type error.