5 ms·

Well right, Zig errors do not have a payload component because Zig is very strict about not having hidden allocations (or control flow) and recognizing the fact

Well right, Zig errors do not have a payload component because Zig is very strict about not having hidden allocations (or control flow) and recognizing the fact that allocations can fail. You are, of course, free to write and use your own error type and handle it however you like, just as in C, but you won't get to use the special error handling syntax Zig has which relies on errors just being integers. Or, as was done here, you can get the information you wanted to include with the error out in any number of other ways. You could have an error stack you push string pointers too, or use logging, etc. Zig just doesn't do that for you because, again, Zig philosophically doesn't allocate willy-nilly.

alpaca128 4y ago
> Zig errors do not have a payload component because Zig is very strict about not having hidden allocations That's likely not the reason. The above article links to a Github issue in which people have been discussing various proposals for handling payloads since 2019, and not a single time it was ruled out because of allocations as those could be handled the same way as anywhere else. Not to mention in many situations an error payload wouldn't necessitate an allocation. For example just allowing a single integer as payload in a parser would already be a huge help. If the language's standard library won't even return a position for JSON parsing errors I'd consider that a problem. Imho it is a mistake to give errors special syntax features without any way of expanding them.
ratorx 4y ago
Zig has tagged unions. Functions can return things other than integers. I don’t see what’s so hidden about allowing unions to be returned as errors. It is all in the functions return type. An error is an abstraction Zig has chosen to provide over an integer. Without discarding any part of their philosophy, they can make this custom abstraction a bit more useful by allowing tagged unions to be errors. Not allocating has nothing to do with not having errors. You can have tagged union errors without any allocation. Rust has them.

alpaca128 4y ago

> Zig errors do not have a payload component because Zig is very strict about not having hidden allocations That's likely not the reason. The above article links to a Github issue in which people have been discussing various proposals for handling payloads since 2019, and not a single time it was ruled out because of allocations as those could be handled the same way as anywhere else. Not to mention in many situations an error payload wouldn't necessitate an allocation. For example just allowing a single integer as payload in a parser would already be a huge help. If the language's standard library won't even return a position for JSON parsing errors I'd consider that a problem. Imho it is a mistake to give errors special syntax features without any way of expanding them.

ratorx 4y ago

Zig has tagged unions. Functions can return things other than integers. I don’t see what’s so hidden about allowing unions to be returned as errors. It is all in the functions return type. An error is an abstraction Zig has chosen to provide over an integer. Without discarding any part of their philosophy, they can make this custom abstraction a bit more useful by allowing tagged unions to be errors. Not allocating has nothing to do with not having errors. You can have tagged union errors without any allocation. Rust has them.