Error union payload cannot cast to the same optional error union payload

kj4tmp · March 23, 2026, 5:48am

I’m pretty sure this code should work, right? Type error{Usage}!T should be castable to type error{Usage}!?T.

const std = @import("std");

fn parseValue(comptime T: type, buf: [:0]const u8) error{Usage}!T {
    switch (@typeInfo(T)) {
        .@"enum" => return std.meta.stringToEnum(T, buf) orelse return error.Usage,
        .optional => |info| return parseValue(info.child, buf),
        else => comptime unreachable,
    }
}

test {
    const Level = enum { err, warn, info, debug };
    try std.testing.expectEqual(.debug, parseValue(?Level, "debug"));
}

$ zig test src/argparser/test2.zig 
src/argparser/test2.zig:6:46: error: expected type 'error{Usage}!?test2.test_0.Level', found 'error{Usage}!test2.test_0.Level'
        .optional => |info| return parseValue(info.child, buf),
                                   ~~~~~~~~~~^~~~~~~~~~~~~~~~~
src/argparser/test2.zig:6:46: note: error union payload 'test2.test_0.Level' cannot cast into error union payload '?test2.test_0.Level'
src/argparser/test2.zig:12:19: note: enum declared here
    const Level = enum { err, warn, info, debug };
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/argparser/test2.zig:3:64: note: function return type declared here
fn parseValue(comptime T: type, buf: [:0]const u8) error{Usage}!T {
                                                   ~~~~~~~~~~~~^~

kj4tmp · March 23, 2026, 6:29am

needs a return try:

const std = @import("std");

fn returns2(comptime T: type) error{Usage}!T {
    switch (@typeInfo(T)) {
        .int => return 2,
        .optional => |info| return try returns2(info.child),
        else => return error.Usage,
    }
}

test {
    try std.testing.expectEqual(2, returns2(?i32));
}

https://codeberg.org/ziglang/zig/issues/31631#issue-3909360

github.com/ziglang/zig

Proposal: allow coercions between optionals and error unions with compatible payloads

opened 06:05PM - 10 Aug 23 UTC

mlugg

proposal

## Motivation Consider the following code: ```zig test { _ = f(); } …fn f() ?u32 { return g(); } fn g() ?u8 { return 123; } ``` This currently fails with a compile error: ``` [mlugg@polaris test]$ zig test foo.zig foo.zig:5:13: error: expected type '?u32', found '?u8' return g(); ~^~ foo.zig:5:13: note: optional type child 'u8' cannot cast into optional type child 'u32' foo.zig:4:8: note: function return type declared here fn f() ?u32 { ^~~~ ``` The error here is a little misleading, since clearly `u8` *can* cast into `u32`. However, we currently require child types of optionals to be *in-memory* coercible. That effectively means that the bytes of the old type can be reinterpreted as the new type, with both types having the same size: for instance, `u32` is IMC to `c_uint` (on platforms where C `int` is 32 bits), and `*[n]T` is in-memory coercible to `[*]T`. This restriction slightly simplifies the compiler implementation, but it leads to this confusing error message. The workaround for this is to use `orelse` to unwrap the optional and re-wrap it, making the body of `f` read `return g() orelse null`. However, this seems redundant, and may be confusing for users (*"isn't `x orelse null` always the same as `x`?"*). The same issue applies to error unions, where the workaround is `eu catch |e| e`, or - in a `return` statement - `return try eu`. ## Proposal Allow the following coercions: * `?A` to `?B`, where `A` can coerce to `B` * `E1!A` to `E2!B`, where `E1` can coerce to `E2` and `A` can coerce to `B` The only real downside I see to this is that it introduces a kind of ambiguity around nested optionals / error unions: how does `?T` coerce to `??T`? In status quo, we effectively get `.{ .payload = x }`, but the new coercions would also make it theoretically valid for the language to instead unwrap the optional, coerce `T` to `?T`, then re-wrap, so `null` gives `@as(??T, null)` rather than `@as(??T, @as(?T, null))`. However, I don't think this is a major issue. The status quo behavior for this coercion seems fairly clearly better, and I believe is what most users would expect, so we can simply define the coercions to retain this behavior, by prioritising the "coerce value to child type" method. Nested optionals / error unions are fairly rare to come across (note that this does not impact types of the form `E!?T`), so I highly doubt this will cause any real confusion. In fact, we already have a case like this - I used it two paragraphs up! `@as(??T, null)` always makes the outermost optional `null`, even though it could be argued that it'd be valid for it to make the outer optional a payload with the inner value being `null`. This doesn't cause a significant amount of confusion, so I don't see a reason this proposal would either.