Rationale behind order of error as a return

Help
21

In Go, the error is at the end merely because of convention. Since errors are values and could be any type, there is no restriction on ordering. You could put the error value before the actual result and not even gofmt would change it. It just wouldnt be idiomatic Go code.

Zig is different. Errors are part of a type in Zig, like Matlad is saying. So the compiler enforces and ordering. And it also forces the unwrap ordering, which is left to right, so you have to unwrap the error before you get the value.

To me, this matches the return type signature. If the catch is the ! then the function call matches error and the right side is the value. In fact if catch provides a value at all, it has to match the return type of get_age.

22

That’s not the order Rust uses: std::result - Rust

It’s

Result<T, E>

I think @matklad is right to suggest that it’s consistently prefixes used in zig. That seems like the simplest reason.

23

oops, i misremembered rust :p.

welcome to ziggit

3 Likes
24

No worries, and thanks! I like the vibes here :slight_smile:

1 Like
25

I think Haskell uses Either.Left (I don’t remember the syntax from the top of my head) for errors and Either.Right for success, by convention in that case.

26

The vibes are in fact immaculate. I say this with love, but some of y’all are so intimidatingly competent that I get surprised you’re also helpful.

4 Likes
27

??you need to be competent to be helpful??

28

The memory layout doesn’t determine the syntax, nor v.v.