Yeah, I agree. I guess “implicit” is misleading here, so I should’ve said that anyerror is “compile-time inferred” instead of “implicit”. But, in essence, anyerror is simply defined as the most general error set, which means that it matches any returned error value.
There is an issue with it, though, whenever it’s used as part of the error union return type anyerror!T or !T, because we actually want the most minimal error set to be written there. At the moment, we have to manually define a specific error set with all its values and then use it instead. I guess the solution could be that the compiler edits the source code and substitutes !T and anyerror!T with specific minimal error sets, like so: error{Value}!T. I’m not quite sure, but I guess “editing source code and reporting compiler errors” is what you meant by “filling in specific error sets and flagging any incorrect switches” during that additional analysis pass, right?
UPD: I guess what you meant was that the specific error sets that right now are explicitly specified as ?[]const Error would be resolved later from someerror to []const Error during that additional final pass. If so, I’m not sure I understand what that deferred inference solves 