eradicate error.Unexpected from the standard library

[andrewrk]

At least where possible, if we can determine that all possible errors are accounted for, remove error.Unexpected from the error set. This issue is deceptively complicated and may involve reading kernel code or wine source code. There may be an argument to keep the error for some syscalls where the system reserves the right to add new error codes.

[shawnl]

I think this is a bad idea. We should not write such fragile code. The default switch case costs us little as it is peeled off into a branch. (Both gcc and llvm have done this for a few years)

[shawnl]

I am worried this will be rejected immediately, however I have an alternate proposal.

We need to preserve the native error codes in error messages. They are not a bad idea (as long as you don't use errno), and are important for debugging.

We have no control over these error codes. During the life-time of a Zig binary they may change, and a Zig binary must not act unpredictably when they do, nor should that binary obscure what the error was when it happens.

Because of this we should reserve the negative values of the internal error union for system errors (on applicable platforms).

For an idea of the syntax:

error.windows.FILE_NOT_FOUND
error.posix.ENOMEM

Only one of these system namespaces can be active in any one compile.

So there is a downside that we can no longer unify errors? NO! Instead of mapping system errors to zig errors, we can map zig errors to system errors. Zig provides no guarantees of what value an error is, so we can just map error.OutOfMemory to both error.posix.ENOMEM and error.windows.NOT_ENOUGH_MEMORY. This way most zig applications never have to see these errors, but they are there if they do need them, at every level and never abstracted out.

Should we provide strerror?

[daurnimator]

Things like seccomp bpf can always add new error codes. Not to mention new kernels coming out with new return values (or old kernels returning ENOTSUP).