-
Notifications
You must be signed in to change notification settings - Fork 354
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
Updated extensibility to discuss non_exhaustive #135
Conversation
A first cut at discussing how `#[non_exhaustive]` should be used
Co-authored-by: Marco Ieni <11428655+MarcoIeni@users.noreply.github.com>
Updated to match the Rust Doc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I miss the discussion when to use privacy
and when to use #[non_exhaustive]
. There are different use cases aren't they?
We should compare them in here and give a small direction for people to let them decide when to use what.
I like that read as well, to understand the background, a # See also
section might be good to add.
# See also
- https://github.com/rust-lang/rfcs/blob/master/text/2008-non-exhaustive.md
And then the # Advantages, # Disadvantages
section could state general arguments for/against(?) field extensibility. While the # Discussion
point can discuss when to use which of them both.
I only see that the advantages being mentioned but not the disadvantages. Most of the time I see this as unnecessary because it prevents the compiler from doing its job to check that the developer handle all the fields. This could be one example, in most cases having a breaking change by adding a new field to an enum is better than using Maybe we should have a good example on both decisions and when to apply (or not to) them. |
Flesh out the discussion
I've fleshed out the discussion some more although I think there's still a bit more to do |
Co-authored-by: Ivan Tham <pickfire@riseup.net>
@pickfire @MarcoIeni Want to give it a read as well? @rcoh What did you want to add to it still? Or is it fine from your side now? |
good from my side |
@rcoh I think only the last review comment is left and fixing the doc test and then we're good to go! :) |
Seems @rcoh lost interest on this. Can a team member finish it? It's a pity that the old article is online while this is almost ready. |
Should be fine now, @MarcoIeni @pickfire might want to read over it once more so we can merge it. |
Co-authored-by: Marco Ieni <11428655+MarcoIeni@users.noreply.github.com>
Thank you everyone. :) |
A first cut at discussing how
#[non_exhaustive]
should be used.Fixes #132