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.