Skip to content

Proposal: Exchange _ for ... in exhaustive enums #4859

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ikskuh opened this issue Mar 30, 2020 · 6 comments
Open

Proposal: Exchange _ for ... in exhaustive enums #4859

ikskuh opened this issue Mar 30, 2020 · 6 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@ikskuh
Copy link
Contributor

ikskuh commented Mar 30, 2020

Follow-up on a discussion with @Tetralux and others on Discord and an improvement for #2524:

The use of _ in exhaustive enums does not communicate intent precisely as it's not clear if there is "something left out", only one item, multiple items. It's not clear to a first-time reader what this symbol is telling us.

The proposal is to exchange it for the ellipsis ... which is already a token in Zig used in the switch range specification, but also is the commonly known symbol for stuff left out:

An ellipsis […] is a series of dots (typically three, such as "…") that usually indicates an intentional omission of a word, sentence, or whole section from a text without altering its original meaning.

The new syntax would be:

enum(u8) {
    a = 0,
    b = 1,
    ...
}
enum(i32) { ... }

I think this communicates much more what is expressed here than the symbol _ which tells the user that "something is ignored".

@daurnimator daurnimator added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Mar 30, 2020
@tecanec
Copy link
Contributor

tecanec commented Mar 30, 2020

We could change the syntax within switch-statements to something like this:

switch (x) {
    0..3 => { // Used to be "0...3"
        doThings();
    },
}

This way, we woudn't have the ... token be used for two things in a simmalar context. It also makes it simmalar to the slicing syntax.
However, as pointed out by @MasterQ32 on Discord, it does mean that .. will mean inclusive in one place and exclusive in another, which may seem wierd.

@andrewrk andrewrk added this to the 0.7.0 milestone Mar 30, 2020
@Tetralux
Copy link
Contributor

Tetralux commented Mar 30, 2020

I said this on Discord, but it bears repeating:
I think ... for this is better, in no small part, because

  • It's easier to grok it when you don't know what it means than _.
  • It's easier to remember having learned it.

Unlike _ =>, I think ... => in switches makes sense since it's the same syntax as what it's representing.

It also only works on non-exhaustive enums so it'd compile error if you were trying to match a range, right? - (Since ranges must always have specified bounds.)
[I'm a bit tired right now, so I may be missing something rather obvious. 😁 ]

@ityonemo
Copy link
Contributor

ityonemo commented Mar 31, 2020

Just a note, for switches using underscore as a catch all match in switches is a common convention in other languages, especially those with pattern matching.

@Tetralux
Copy link
Contributor

@ityonemo _ is not a catch-all in Zig. It's specifically for non-exhuastive enums. else => is the catch-all.

@pixelherodev
Copy link
Contributor

Not sure it means much, but I extend my support for this!

@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 27, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 23, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
@ProkopRandacek
Copy link
Contributor

another option that crossed my mind is adding a keyword similar to packed:

nonexhaustive enum(u8) {
    a = 0,
    b = 1,
}

which declares the union type upfront instead of having to scan to the end.
thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

8 participants