Skip to content
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

Wishlist: marker for open-ended enums #943

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
Contributor

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
Contributor

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
Contributor

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
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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