Error sets inferred to be empty still need to be unwrapped with try/catch

[alexnask]

Example:

fn foo(arg: var) !void {
    // Do stuff, conditionally return an error based on @TypeOf(arg)
    // No error for this instantiation after all!
}

pub fn main() void {
    foo(42); // error: expression value is ignored
}

[MasterQ32]

I think that's the wanted use case. The function says it will probably return an error in future implementations, but cannot fail atm. So all invocations of foo will require try, even if it's a no-op

[Sobeston]

I think that this is useful for future api compatibility. A library may have a function which may not error now, but may error in future versions. I've seen this pattern used often in go codebases where a function always returns a "nil" error.

[daurnimator]

Yes this is intentional: without it you couldn't do a pattern like:

fn foo(comptime: Error: type, func: fn() Error!void) !void {
  return try func();
}

which is pretty common in zig (see e.g. streams).

I don't know why you would want the inconsistency of the empty error set not needing try.

[BarabasGitHub]

I was going to make an issue that it doesn't complain when an function that says it can return an error doesn't return an error. In other words, this is allowed and compiles without error:

fn function() !void {}

but I guess that is as intended due to the above mentioned use case of maybe returning an error in the future?

[tadeokondrak]

@BarabasGitHub, that was the old behaviour, but was recently changed: #4564

[SpexGuy]

The catch clause doesn't get compiled when the error set is empty, so you can safely do something like this as a workaround:

pub fn wrapper(x: var) void {
    impl(x) catch @compileError(@typeName(@TypeOf(x)) ++ " may cause an error, call impl instead.");
}

That said, I agree with the OP that maybe this should work. Changing the error set of a function is a change to it's interface, and it's expected to have to update all call sites when a function's interface changes. So adding an error in the future isn't a valid reason to require catch now.

The real question in my mind is whether error{}!T should be equivalent to T. If they are the same, then no try should be required (but this has other weird consequences). If they are different, then error{}!T is an error set type and should follow the rules of error set types for simplicity, similar to how ?void still requires a capture when unwrapped with if or while.

That said, we have precedent for the opposite too. Expressions returning void are allowed to discard their value or put it into a variable. If error{} is analogous to void in this case, then it makes sense that handling and discarding the error should both be valid.

Another option would be to redefine inferred error sets to say that if no error set is inferred it returns T, not error{}!T. But this would be kind of a discontinuity in the language. Still maybe worth thinking about though.