Utilizing the versioned prelude

Add a new key to Cargo.toml, package.prelude (optionally, lib.prelude and bin.prelude, but matching edition and only setting in one place makes sense). The default value when unset is v1, which retains today's prelude import of ::[std|core]::prelude::v1::*. It can be set to "any" other identifier string, which will make the prelude instead be ::[std|core]::prelude::{package.prelude}::*.

Alternatively, make package.prelude an array of anchored paths (the default being ["::[std|core]::prelude::v1"]), all of which are imported as prelude for the package. This would give full custom prelude powers.

Implementation: rustc grows a new flag to pass the used prelude path(s), rather than always using ::[std|core]::prelude::v1. Some magic identifier is used to select std/core.


Tying the prelude to the edition would also make sense, but if we were going to do that then it should probably have been done when the 2018 edition was published. We could still make std::prelude::e2015/e2018 aliases for v1 and add e2021 if we wanted to tie default prelude to the edition with this scheme, however.

2 Likes

I'm not a fan of having these things as flags / cargo rather than in code; that seems less self-contained.

If we want to pursue user defined preludes then @aturon's RFC https://github.com/rust-lang/rfcs/pull/890 seems like the better option.

Where there's a need, I think we should try extending the v1 prelude using crater data. I think it's pretty premature to talk about splitting the prelude into more versions when we don't even have a proposal for adding things to that prelude nor have we checked what parts of that proposal can be done in v1. Once we know what things cannot go into v1 let's then make a list for Edition.Next's prelude.

1 Like