Skip to content

Wishlist: marker for open-ended enums #943

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

Closed
aturon opened this issue Mar 5, 2015 · 7 comments
Closed

Wishlist: marker for open-ended enums #943

aturon opened this issue Mar 5, 2015 · 7 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@aturon
Copy link
Member

aturon commented Mar 5, 2015

Previous RFC:

A mechanism for declaring an enum to be extensible, which prevents exhausting matching in downstream crates.

@aturon aturon added postponed RFCs that have been postponed and may be revisited at a later time. A-wishlist labels Mar 5, 2015
@aturon aturon mentioned this issue Mar 5, 2015
@clarfonthey
Copy link

Hey, I think that putting out a new RFC for something like this might like up with 2017's goals, considering how it'll make a much-desired feature for enums simple instead of cryptic (via #[doc(hidden)]).

What do people think?

@Mark-Simulacrum
Copy link
Member

There's quite a bit of interesting discussion in rust-lang/rust/issues/32770; worth taking a look at if anyone is planning to write an RFC.

@clarfonthey
Copy link

I'd be more than willing to modify the existing RFC that was postponed to change the dedicated syntax to a special attribute. Mostly I'm just curious if it'd make sense to make one now or if the core team would rather make the change later.

@Mark-Simulacrum
Copy link
Member

cc @rust-lang/lang, @clarcharr seems willing to drive an RFC on this topic. Can we get a preliminary go-ahead or otherwise?

@clarfonthey
Copy link

Clarifying a bit on the idea I have:

This would add an #[non_exhaustive] attribute that can be added to enums to indicate that matches outside the current crate must include a wildcard pattern. We'd remove this restriction for inside the crate because if the enum is changed, it's reasonable for the crate author to update code elsewhere inside the same crate.

@clarfonthey
Copy link

clarfonthey commented May 25, 2017

So I decided to write this up anyway and we'll see what people think. It's at #2008.

@leoyvens
Copy link

Given we have an accepted RFC, I believe this issue can be closed.

@petrochenkov petrochenkov added T-lang Relevant to the language team, which will review and decide on the RFC. and removed postponed RFCs that have been postponed and may be revisited at a later time. labels Feb 24, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

5 participants