Tracking issue for alloc::prelude

[SimonSapin]

Its stability was separated from that of the alloc crate in #58933.

CC rust-lang/rfcs#2480

[roblabla]

The alloc_prelude feature gate seems to be broken: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=808681d68a06487853e5d2d3416fd332 compiles and runs just fine without specifying the #![feature(alloc_prelude)] feature gate.

[SimonSapin]

This is a case of #15702.

(The documented example use alloc::prelude::v1::*; does require the feature gate.)

[LukasKalbertodt]

What exactly is blocking stabilization? Any unresolved questions? Just gaining experience with it?

[SimonSapin]

I think there was a question of how useful this is, since unlike core::prelude or std::prelude this isn’t injected automatically in any crate. Feedback from projects who use it despite this or would like to use it despite this would be helpful.

[LukasKalbertodt]

I think it is very useful.

I commented here after trying to use alloc::prelude for stable-vec which is no_std with alloc. The crate started, as probably most no_std crates, as a normal crate with std. Thus, across the codebase I used symbols such as Vec. To make the transition to alloc as easy as possible, crates should be able to just use alloc::prelude::*; to not import symbols like Vec manually. Especially if the crate also has an std feature which conditionally uses std to enabled more features. Because in that later case, the crate would have to conditionally compile even more import statements, leading to a mess.

In the end, I stopped baking my own solution and used no-std-compat. But even that crate would benefit from a stable alloc::prelude. Look at this code:

pub mod prelude {
    pub mod v1 {
        // Prelude
        pub use __core::prelude::v1::*;
        #[cfg(all(feature = "alloc", feature = "unstable"))]
        pub use __alloc::prelude::v1::*;
        #[cfg(all(feature = "alloc", not(feature = "unstable")))]
        pub use __alloc::{
            borrow::ToOwned,
            boxed::Box,
            // UNSTABLE: slice::SliceConcatExt,
            string::String,
            string::ToString,
            vec::Vec,
        };

        // Other imports
        #[cfg(feature = "alloc")]
        pub use __alloc::{format, vec};
        #[cfg(feature = "compat_macros")]
        pub use crate::{print, println, eprint, eprintln, dbg};
    }
}

So if the unstable feature of that crate is not enabled, it has to manually list the prelude symbols.

So I think alloc::prelude is useful and I don't see a reason not to include it. I don't see how this could be abused/lead to worse code/could limit future developments of the language or the alloc crate. It just seems very natural to have. alloc is a subset of std, so I want alloc::prelude to be a subset of std::prelude.

[elichai]

I think there was a question of how useful this is, since unlike core::prelude or std::prelude this isn’t injected automatically in any crate.

Why not auto inject it if alloc is enabled?

[SimonSapin]

This would add “more magic” to the language. It’s possible, but I feel it should go through the RFC process to get consensus of whether to go in that direction.

[elichai]

This would add “more magic” to the language. It’s possible, but I feel it should go through the RFC process to get consensus of whether to go in that direction.

I might actually try to write one(have no experience in writing RFCs) if you think it's needed.
I think it can make it really easier to add a alloc only feature for crates.(and more importantly maintain it)
(although maybe one day we could use the replace sysroot feature to somehow pass --alloc-only flag to the compiler which will auto-magically do this for us without editing the crate)

[jhpratt]

Is there any harm in stabilizing the module itself, then deciding whether to auto-import it at a later time? I'd like to be able to use the module, as right now I've literally code identical code in a module to import in the same manner.

[Amanieu]

We discussed this in the libs meeting and felt that we shouldn't have a prelude module in alloc unless it is auto-imported like the preludes in core and std. This could be implemented in the future as an extension to #![no_std] such as #![no_std(alloc)] which would also remove the need for extern crate alloc.

Until such a feature is introduced, we don't think alloc::prelude should be stabilized.

@rfcbot close

[rfcbot]

Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[SimonSapin]

an extension to #![no_std] such as #![no_std(alloc)] which would also remove the need for extern crate alloc

Oh I hadn’t heard of that idea before. It sounds nice!

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.