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