Can/should things like Box<T, A> move to libcore?

[scottmcm]

Given that Alloc is defined in core::alloc -- and alloc::alloc::Alloc is just a re-export -- would be be reasonable for things like Box to live in libcore? It seems like it would work, there just wouldn't be a default for the type parameter when using it from core instead of alloc or std...

[glandium]

You could say the same for almost everything in liballoc...

[SimonSapin]

Yes. On principle, if there’s a "version" of an allocator-generic container without a default allocator, there’s no reason not to have it in libcore.

But how do we make that happen? Does pub type Box<T, A = Global> = core::boxed::Box<T, A>; work correctly, even with type inference? Are are you thinking of wrapper structs?

[glandium]

See rust-lang/rust#50882 (comment)

[Ericson2314]

I don't want to make core bigger, I want to separate the compiler-specific vs compiler-agnostic (purely stable Rust) parts of std and core so move library development can work independent and in parallel of rustc's release schedule (as long as it doesn't make any breaking interface changes).

[gnzlbg]

@Ericson2314 that sounds more like splitting libcore into a liblangitem sub-component, that's tied to the compiler, and layering the compiler agnostic stuff on top. While this might be desirable, there are other issues to balance, e.g., due to coherence, we can't implement traits from liblangitem for types declared in liblangitem outside of liblangitem, we can't implement methods for types inliblangitem outside of liblangitem without doing so via a trait, which has its own issues (e.g. trait methods can't be const fn yet, etc.), etc.

[Ericson2314]

@gnzlbg yes it is hard and yes I'd like to make existing core a facade too. But that is another reason why I'd like to not put things in core now. Even if we agree to split it up later, if those items get entangled with everything else in the meantime it will be a lot harder than if those items lived in their own crate from the get-go.

[TimDiekmann]

that sounds more like splitting libcore into a liblangitem

As Box is tied to the compiler, Box would even fit into liblangitem.