Repository navigation
Tracking issue for the 2018 edition’s prelude #51418
Description
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.
Activity
SimonSapin commentedon Jun 7, 2018
(Not exactly, but close enough for an easier explanation. The relevant code is in
src/libsyntax/std_inject.rs.)eddyb commentedon Jun 7, 2018
Should we rename
v1toedition2015and add an alias for it? Then the compiler can just plug in the edition year into the path.SimonSapin commentedon Jun 7, 2018
@eddyb Maybe. Either way seems easy enough for the compiler.
clarfonthey commentedon Jun 8, 2018
I really like naming the preludes after the editions instead sequential
v1, etc., although I'd suggest going withrust2015instead ofedition2015.clarfonthey commentedon Jun 8, 2018
Also, what I think should be added, ordered from most important to least important:
TryFromandTryInto: Already proposed. Generic conversions happen often.Hash: Used in generic code, usually when something would like to store values in aHashMaporHashSet. While this presumably was left out due to it making thehashandhash_slicemethods 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.DebugandDisplay: 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 commentedon Jun 8, 2018
@clarcharr The advantage of having
DebugandDisplayin the prelude is that now we can just useDebug::fmtandDisplay::fmtand it's not much worse than if we haddebug_fmt&display_fmt.[-]Different (extended) prelude for the 2018 edition[/-][+]Tracking issue for the 2018 edition’s prelude[/+]matklad commentedon Jun 11, 2018
Yes please! I often find myself using deprecated
::std::thread::sleap_ms(1000), because reaching forDurationis to long.EDIT: alternative solution for this specific problem: #51610
IIRC, names in prelude are shadowed by anything, including
*imports, so I think it is not possible to get a conflict by adding astructto 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 commentedon Jun 17, 2018
@clarcharr Other than
TryFromandTryInto, 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 commentedon Jun 18, 2018
#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
TryFromandTryIntotostd::prelude::v1and not have a separate 2018-edition prelude at all.2 remaining items
scottmcm commentedon Jul 31, 2018
The lang team discussed this; here are my take at some notes:
TryFrom&TryIntoseemed like a good set.But there was an observation made that
unstable_name_collisionsalready 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 commentedon Nov 14, 2018
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 commentedon Nov 14, 2018
We can still do the libcore/libstd organizational changes, right?
If only to provide a precedent for Rust 2021 to build upon.
SimonSapin commentedon Nov 14, 2018
Sorry, it’s been a while. What changes are those?
eddyb commentedon Nov 14, 2018
I just mean having e.g.
std::prelude::{rust2015, rust2018}etc. instead ofv1(we can't removev1, but we could deprecate it).oconnor663 commentedon Jan 21, 2020
Should we think about re-opening this for the 2021 edition? Or better to start a new thread?
bstrie commentedon Jan 21, 2020
@oconnor663 there appears to be a new thread at #65512 , I'd suggest anyone else interested in this should migrate there as well.
Rollup merge of rust-lang#82217 - m-ou-se:edition-prelude, r=nikomats…
Rollup merge of rust-lang#82217 - m-ou-se:edition-prelude, r=nikomats…