MCP: per-edition preludes

[scottmcm]

Proposal

Summary and problem statement

To give libs more flexibility, we should allow different preludes per edition.

Motivation, use-cases, and solution sketches

Due to nuances of trait resolution, adding a trait to the prelude is a (technically allowed) breaking change. To help avoid heavy impact, however, it would be nice to be able to make those changes opt-in. The edition mechanism seems like a reasonable place to do this: it means that new code (using cargo new, which defaults to the new edition) will get the new traits in its prelude, but old code using traits that conflict won't be immediately broken.

The basic change here is easy: instead of putting use std::prelude::v1::*; in every module, put use std::prelude::v2018::*; (or analogously for other editions). Giving edition warnings and structured fixes would be much harder, I suspect.

EDIT: petrochenkov points out that preludes for macros may also be hairy.

Out of scope

I would like to leave what, if anything, would change in such a prelude out of scope from this conversation. We can start with all of them being the same as the (could then be deprecated) v1 module. And lang and/or libs can then consider individual changes in a future edition (or existing ones) as separate changes.

Prioritization

This fits decently under "Targeted ergonomic wins and extensions". Having TryInto available in the prelude, for example, would help the compiler give error messages on conversions mentioning that without the confusion of the suggestion not working until an additional trait is used.

Links and related work

rust-lang/rust#65512

Initial people involved

@scottmcm

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[nikomatsakis]

Discussed in rust-lang meeting today:

• We would like to have the capability of modifying the prelude over an edition, so this is worth doing.
• However, we do probably need to do that work, but we're not sure who is best (or has bandwidth) to do the work.
• We would like to encourage the interaction with macros and report back. @scottmcm will leave some comments to that effect. =)

Leaving unresolved for now.

[nikomatsakis]

Discussed in rust-lang meeting today:

• We generally approve of the concept but we would need to have an idea who is being "chartered" to work on this (perhaps @scottmcm is volunteering to serve as the liaison).

Leaving unresolved for now.

[joshtriplett]

Discussed today: still seeking a project group to drive this forward.

[nikomatsakis]

Update from 2020-09-14:

Last week we felt like this really needs to be delegated to the @rust-lang/libs team. This is something we're prepared to do work on if the libs team has a proposal for how to use it. Actual change of what should be in the new prelude is up to the libs team (as the proposal itself states).

We don't really feel like an RFC is required for this. It feels like the next step would be the implementation work from the compiler side and we would FCP the PR.

There we are entering final comment period about the intention that we would like to see this proposal implemented and we can FCP the PR.

[scottmcm]

I'm fine with closing this for tracking from our side. Hopefully someone will implement it.

[nikomatsakis]

Update from 2020-09-21:

Closing per the above comment. There has been some @rust-lang/libs discussion, which is good.