3 ms·
What they're trying to convey is that errors are structurally typed. If you declare: const MyError = error{Foo} in one library and: const TheirError
by jamii 2y ago
What they're trying to convey is that errors are structurally typed. If you declare:
const MyError = error{Foo}
in one library and:
const TheirError = error{Foo}
in another library, these types are considered equal. Unlike structs/unions/enums which are nominal in zig, like most languages.
The reason for this, and the reason that errors are not regular records, is to allow type inference to union and subtract error types like in https://news.ycombinator.com/item?id=42943942 https://news.ycombinator.com/item?id=42943942. (They behave like ocamls polymorphic variants - https://ocaml.org/manual/5.3/polyvariant.html https://ocaml.org/manual/5.3/polyvariant.html) This largely avoids the problems described in https://sled.rs/errors.html#why-does-this-matter https://sled.rs/errors.html#why-does-this-matter.
On the other hand zig errors can't have any associated value (https://github.com/ziglang/zig/issues/2647 https://github.com/ziglang/zig/issues/2647). I often find this requires me to store those values in some other big sum type somewhere which leads to all the same problems/boilerplate that the special error type should have saved me from.
- throwawaymaths 2y agoif you need values associated with your error you can stash them in an in-out parameter
- jamii 2y agoIf I have multiple errors then that in-out parameter has to be a union(enum). And then I'm back to creating dozens of slightly different unions for functions which return slightly different sets of errors. Which is the same problem I have in rust. All of the nice inference that zig does doesn't apply to my in-out parameter either. And the compiler won't check that every path that returns error.Foo always initializes error_info.Foo.
- throwawaymaths 2y agoi dont think you can make a union that has an error enum tag. I dont see why the in-out has to be dependent on the error.