Open scottmcm opened 5 years ago
You could say the same for almost everything in liballoc...
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?
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).
@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.
@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.
that sounds more like splitting
libcore
into aliblangitem
As Box
is tied to the compiler, Box
would even fit into liblangitem
.
Given that
Alloc
is defined incore::alloc
-- andalloc::alloc::Alloc
is just a re-export -- would be be reasonable for things likeBox
to live inlibcore
? It seems like it would work, there just wouldn't be a default for the type parameter when using it fromcore
instead ofalloc
orstd
...