-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
A new prelude for the 2021 edition (trait-only edition) #3114
Conversation
981eb6d
to
b88bcf0
Compare
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.
Thanks!
A few comments:
There's a few comments and small details that need to be addressed before we can merge this. But I'm starting the libs FCP process now to not delay this any further. We already discussed these additions in a meeting earlier this year, but we still need formal approval for these prelude additions. Specifically, this RFC proposes to make the prelude dependent on the edition, and to add to add three traits to the Rust 2021 prelude:
@rfcbot merge |
Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
Looks good to me. Conditional based on the existing comments all being resolved: @rfcbot reviewed |
Co-authored-by: Kornel <[email protected]>
Co-authored-by: Mara Bos <[email protected]>
Nit Pick: The inherent impl |
Oh, that's good to know. Do you have a reference for that? |
So, yeah, we should just put Not in the darn prelude in 2021 and get all this nonsense over with. |
Putting just Not in and not the various other unary operators or even all operators would be pretty inconsistent. Since it's also potentially a pretty strong idiomatic shift even (with many people adopting it and many not), it seems too controversial to just slip into an RFC of common not so controversial imports, especially if this would only be a workaround to the path ahead of adding inherent trait impls. |
this feels like an overstatement of the situation. It's a single method. |
@nikomatsakis Can you sign off on the migration plan? @BurntSushi @dtolnay @sfackler If any of you have time to review this; would be nice to start the FCP soon. (Sorry for the rush, but it'd be nice if we can finish the list of 2021 edition changes before publishing the blog post. This is the last one that still needs fcp. :) ) |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
LGTM. Thanks for putting this together! With respect to With respect to naming, I personally would prefer |
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 approve the migration lint description =)
Some data: There are zero matches for |
@m-ou-se Ah okay. That's enough to change my preference then. Thanks for that data! |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
Huzzah! The @rust-lang/libs team has decided to accept this RFC. To track further discussion, subscribe to the tracking issue here: rust-lang/rust#85684 |
New prelude RFC: rust-lang/rfcs#3114 Tracking issue: rust-lang#85684
…joshtriplett Stabilize {std, core}::prelude::rust_*. This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules. The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them. Tracking issue: rust-lang#85684 FCP on the RFC that included this finished here: rust-lang/rfcs#3114 (comment)
Maybe I'm too late, but I want to suggest adding |
…joshtriplett Stabilize {std, core}::prelude::rust_*. This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules. The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them. Tracking issue: rust-lang#85684 FCP on the RFC that included this finished here: rust-lang/rfcs#3114 (comment)
…joshtriplett Stabilize {std, core}::prelude::rust_*. This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules. The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them. Tracking issue: rust-lang#85684 FCP on the RFC that included this finished here: rust-lang/rfcs#3114 (comment)
…_lint, r=nikomatsakis Add `future_prelude_collision` lint Implements rust-lang#84594. (RFC rust-lang/rfcs#3114 ([rendered](https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md))) Not entirely complete but wanted to have my progress decently available while I finish off the last little bits. Things left to implement: * [x] UI tests for lints * [x] Only emit lint for 2015 and 2018 editions * [ ] Lint name/message bikeshedding * [x] Implement for `FromIterator` (from best I can tell, the current approach as mentioned from [this comment](rust-lang#84594 (comment)) won't work due to `FromIterator` instances not using dot-call syntax, but if I'm correct about this then that would also need to be fixed for `TryFrom`/`TryInto`)* * [x] Add to `rust-2021-migration` group? (See rust-lang#85512) (added to `rust-2021-compatibility` group) * [ ] Link to edition guide in lint docs *edit: looked into it, `lookup_method` will also not be hit for `TryFrom`/`TryInto` for non-dotcall syntax. If anyone who is more familiar with typecheck knows the equivalent for looking up associated functions, feel free to chime in.
…int, r=nikomatsakis Add `future_prelude_collision` lint Implements rust-lang#84594. (RFC rust-lang/rfcs#3114 ([rendered](https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md))) Not entirely complete but wanted to have my progress decently available while I finish off the last little bits. Things left to implement: * [x] UI tests for lints * [x] Only emit lint for 2015 and 2018 editions * [ ] Lint name/message bikeshedding * [x] Implement for `FromIterator` (from best I can tell, the current approach as mentioned from [this comment](rust-lang#84594 (comment)) won't work due to `FromIterator` instances not using dot-call syntax, but if I'm correct about this then that would also need to be fixed for `TryFrom`/`TryInto`)* * [x] Add to `rust-2021-migration` group? (See rust-lang#85512) (added to `rust-2021-compatibility` group) * [ ] Link to edition guide in lint docs *edit: looked into it, `lookup_method` will also not be hit for `TryFrom`/`TryInto` for non-dotcall syntax. If anyone who is more familiar with typecheck knows the equivalent for looking up associated functions, feel free to chime in.
As requested by the Libs team (via @m-ou-se), here's a smaller, trait-only 2021 prelude RFC. This also addresses some of the feedback from RFC 3090 and includes a more detailed migration lint design.
Rendered