-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
make noreturn
type more like the "zero" type
#3257
Comments
noreturn
type feels like a second class citizen in Zignoreturn
type more like the "zero" type
Another use for this: |
I feel like this is the "right thing". @vi do you have an example use case for this one? |
@daurnimator , Obvious one is codegenerated Zig code where union variants are filled in by automatic algorithm. Special cased error because of something happens to be empty leads to special cases and workarounds in code generator (i.e. removing the type altogether or adding a dummy variant). If empty unions definitions and (also empty) switch statements on those unions are allowed, less corner cases need to be considered in code generator. Another case is temporary commenting out some code. Commenting out the last union variant leads to bigger reorganisation. Think of "trailing comma, but in the world of types". |
Tagged union of 2 bools ( You need 2 |
Rust originally special cased In both of these cases, the languages already had a concept of an "uninhabited type", such as an enum with zero variants. I think Zig should also make empty enums/unions work, and make
|
?noreturn
is not allowed instead of beingvoid
-equivalent (alwaysnull
). Likeu0
is currentlyvoid
-equivalent.noreturn
-equivalent.T=noreturn
noreturn
for union variant does still allocate a tag for such variantJava gets unit and zero types wrong. Rust gets unit and zero types (relatively) right. Zig gets unit type right, but zero type wrong. Shall it be fixed?
The text was updated successfully, but these errors were encountered: