9

Github A new prelude for the 2021 edition (trait-only edition) by djc · Pull Req...

 3 years ago
source link: https://github.com/rust-lang/rfcs/pull/3114
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Conversation

Copy link

Contributor

djc commented 11 days ago

edited

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

Copy link

Member

m-ou-se commented 9 days ago

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:

  • TryInto
  • TryFrom
  • FromIterator

@rfcbot merge

Copy link

rfcbot commented 9 days ago

edited by BurntSushi

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.

Copy link

Contributor

yaahc commented 8 days ago

Looks good to me.

Conditional based on the existing comments all being resolved:

@rfcbot reviewed

Copy link

Contributor

Lokathor commented 7 days ago

Nit Pick: The inherent impl not method on bool was already rejected from being added to core on the grounds that people would get an unused import warning, and so we'll have to wait for some inherent traits proposal to be accepted and stabilized (which could take far longer than the 2021 edition)

Copy link

Contributor

Author

djc commented 7 days ago

Oh, that's good to know. Do you have a reference for that?

Copy link

Contributor

Lokathor commented 7 days ago

rust-lang/rust#82786

So, yeah, we should just put Not in the darn prelude in 2021 and get all this nonsense over with.

Copy link

CryZe commented 7 days ago

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.

Copy link

Contributor

Lokathor commented 7 days ago

pretty strong idiomatic shift

this feels like an overstatement of the situation. It's a single method.

Copy link

Member

m-ou-se commented 4 days ago

@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. :) )

Copy link

rfcbot commented 4 days ago

bellThis is now entering its final comment period, as per the review above. bell

Copy link

Member

BurntSushi commented 4 days ago

LGTM. Thanks for putting this together!

With respect to Not, I agree with @CryZe's perspective here.

With respect to naming, I personally would prefer rust2021 instead of rust_2021. I find the former far more aesthetically pleasing, to the point that it outweighs any rigorous consistency argument with naming elsewhere. With that said, I don't believe that these are names that folks will be uttering or even reading frequently, so this is a pretty minor point.

Copy link

Contributor

nikomatsakis left a comment

I approve the migration lint description =)

Copy link

Member

m-ou-se commented 4 days ago

With respect to naming, I personally would prefer rust2021 instead of rust_2021. I find the former far more aesthetically pleasing, to the point that it outweighs any rigorous consistency argument with naming elsewhere. With that said, I don't believe that these are names that folks will be uttering or even reading frequently, so this is a pretty minor point.

Some data: There are zero matches for rust20\d\d in compiler/, but 53 matches for rust_20\d\d. We already have user-facing names like #![warn(rust_2018_idioms)] with underscores. Internally in rustc it's written like that too for functions like span.rust_2018().

Copy link

Member

BurntSushi commented 4 days ago

@m-ou-se Ah okay. That's enough to change my preference then. Thanks for that data!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK