Tracking issue for the 2018 edition’s prelude

[SimonSapin]

Currently, every module has something like use std::prelude::v1::*; implicitly inserted into it by default.

In #49305 we added the TryFrom and TryInto traits to the prelude, and reverted that in #49518 because that a breaking change for a significant number on crates that had their own TryFrom or TryInto traits. (Ironically, identical to the std ones and duplicated because those were still unstable.)

Consensus is that we’d still like to have those traits in the prelude, but to avoid breakage we need to make that opt-in. The upcoming 2018 edition seems to be a good opportunity for that. For modules in crates that opt into the 2018 edition, we could replace v1 in that inserted code with edition2018 and create src/libstd/prelude/edition2018.rs and src/libcore/prelude/edition2018.rs like so:

pub use super::v1::*;
pub use convert::{TryFrom, TryInto};

Are there more items we considered adding to the prelude but didn’t because of breakage or breakage risk?

---

Update: implemented in #51434.

[SimonSapin]

every module has something like use std::prelude::v1::*; implicitly inserted into it

(Not exactly, but close enough for an easier explanation. The relevant code is in src/libsyntax/std_inject.rs.)

[eddyb]

Should we rename v1 to edition2015 and add an alias for it? Then the compiler can just plug in the edition year into the path.

[SimonSapin]

@eddyb Maybe. Either way seems easy enough for the compiler.

[clarfonthey]

I really like naming the preludes after the editions instead sequential v1, etc., although I'd suggest going with rust2015 instead of edition2015.

[clarfonthey]

Also, what I think should be added, ordered from most important to least important:

• TryFrom and TryInto: Already proposed. Generic conversions happen often.
• Hash: Used in generic code, usually when something would like to store values in a HashMap or HashSet. While this presumably was left out due to it making the hash and hash_slice methods available on a majority of types, I feel like this is outweighed by the usefulness of having the type available.
• FusedIterator: Used in generic code, and the name is very unlikely to clash with anything.
• RangeBounds: Same as above.
• Duration: While this isn't used very often, any code which works with time will likely want this. A bit fuzzy on the inclusion, as it's more likely to cause name conflicts.
• Debug and Display: These would be higher on the list if it weren't for the fact that both traits share the same method name: fmt. They're often used in generic code and I feel like not having to import them when using them would be a plus.

[eddyb]

@clarcharr The advantage of having Debug and Display in the prelude is that now we can just use Debug::fmt and Display::fmt and it's not much worse than if we had debug_fmt & display_fmt.

[matklad]

Duration: While this isn't used very often, any code which works with time will likely want this.

Yes please! I often find myself using deprecated ::std::thread::sleap_ms(1000), because reaching for Duration is to long.

EDIT: alternative solution for this specific problem: #51610

as it's more likely to cause name conflicts.

IIRC, names in prelude are shadowed by anything, including * imports, so I think it is not possible to get a conflict by adding a struct to prelude.

The situation with traits specifically is more difficult: although traits themselves enjoy shadowing, trait methods do not, so ambiguous method call between explicitly and glob imported trait is a compile-time error (I haven't thought about it deeply, but looks like it should be possible, and even natural and consistent, to extend shadowing behavior to trait's methods? (EDIT: filed #51497)).

[SimonSapin]

@clarcharr Other than TryFrom and TryInto, was there suspected or observed compat risk with adding those to the 2015 prelude? If not, feel free to propose adding them regardless of this issue (which is about having a different prelude per-edition).

@matklad Exactly, the name collision was not with the traits themselves but with the methods that are in scope.

[SimonSapin]

#51434 had a naïve implementation but was missing something required by https://rust-lang.github.io/rfcs/2052-epochs.html#a-broad-policy-on-epoch-changes: a warning for 2015-edition code that would break with the new prelude.

Unfortunately I don’t know how to go about implementing that warning, so any help here is appreciated.

Alternatively, tweaking the method resolution rules so that methods from traits that are only in scope through the prelude have “less priority” and do not collide with other methods would allow us to add TryFrom and TryInto to std::prelude::v1 and not have a separate 2018-edition prelude at all.

[liigo]

FusedIterator: Used in generic code, and the name is very unlikely to clash with anything.
RangeBounds: Same as above.
Duration: While this isn't used very often, any code which works with time will likely want this. A bit fuzzy on the inclusion, as it's more likely to cause name conflicts.

"very unlikely to clash with anything" may applies to many many other types.

[scottmcm]

The lang team discussed this; here are my take at some notes:

• The idea of preludes being per-edition was received positively.
• There was a strong desire to limit the conversation for now to those things that must be edition-tied, and thus not add any concrete types at this time, as that can be done at any time.
• Adding TryFrom & TryInto seemed like a good set.
• So the question boiled down to how to get the linting right.

But there was an observation made that unstable_name_collisions already exists, and that ! (and thus TryFrom/Into) are not going to be stable in time for the edition. Thus, the prelude edition is non-breaking; it'll end up just being more like an idiom lint in that it turns on once you're in the edition. And then stabilizing is a de jure non-breaking change, since it's just to method resolution, but it'll hopefully be lower impact as everyone will have been heavily warned about it, and it won't break all the older crates the way that adding them to the 2015 prelude would have.

How do people feel about that approach?

[SimonSapin]

I kinda dropped the ball here and nobody picked it up. The 2018 edition is stable in Rust 1.31 which is now in beta so it’s likely too late for this, closing.

[eddyb]

We can still do the libcore/libstd organizational changes, right?
If only to provide a precedent for Rust 2021 to build upon.

[SimonSapin]

Sorry, it’s been a while. What changes are those?

[eddyb]

I just mean having e.g. std::prelude::{rust2015, rust2018} etc. instead of v1 (we can't remove v1, but we could deprecate it).

[oconnor663]

Should we think about re-opening this for the 2021 edition? Or better to start a new thread?

[bstrie]

@oconnor663 there appears to be a new thread at #65512 , I'd suggest anyone else interested in this should migrate there as well.