#Should I return catch return, or just return catch?

1 messages · Page 1 of 1 (latest)

compact kelp
#

I think either is fine.
the reason both are allowed is because of the way control flow expressions work in zig. return as an expression has a type noreturn, meaning it coerces to any value (which is fine, because said coercion will never actually happen - same reason you can put unreachable anywhere without violating the type system). So essentially, in the first one, you are performing peer type resolution on E!T and noreturn, and in the second one, you're performing peer type resolution on E1!T and E2!T (or maybe it just returns an E2 value directly, which is also fine).

#

not familiar with the term "bottom type".

#

I see, well, I'm not familiar with the usage, but if you mean a type that is considered by the type system to never have a value (as opposed to having only one value, like a unit type), then yes, that'd be accurate

compact kelp
#

well, my interpretation is that it means that an expression with that type does not evaluate to a value, aka it doesn't "return" anything. So return is noreturn because the expression return itself does not return a value to the location it's being "assigned" to, which is distinct from the effect it has, which is to return a value from the enclosing function.

mossy python
#

effectively, yeah. it's semantically equivalent to something like enum {} - a type with no values

compact kelp
#

isn't set in stone, I don't think we've bikeshed a lot on the naming

#

it was just recently updated to be a bit more like rust's never type in a few respects, so we might adopt that naming convention at some point to improve clarity

#

we'll see

mossy python
#

the old proposal for ranged int types suggests that you could define noreturn = @Int(0, 0) although tbh idk why you couldn't define it as noreturn = enum {} today

compact kelp
#

so you'd first have to introduce that as a feature

mossy python
compact kelp
#

nah, if you actually use it in runtime code it segfaults

mossy python
#

i mean the point is that you can't use it

compact kelp
#

yeah, and there's no way to construct it either, like you can with built-in noreturn types, so not that useful

#

also, stage1 does issue a compile error for it

mossy python
#

yeah currently it's useless, my point was just that in theory it's semantically identical to noreturn so i don't see a reason it couldn't be implemented like that

mossy python
compact kelp
#

so either it has been changed to not error, or that's a bug

mossy python
#

There's not really an equivalent, since Zig is a low-level strongly typed language. The closest parallel is anytype but that isn't an actual type