Description
Background on [T] methods
Inherent methods for slices are currently defined in liballoc with:
#[lang(slice)]
impl<T> [T] {
// …
}#[lang(slice)] is an escape hatch to allow that impl to exist. Normally it wouldn’t be allowed since liballoc is not the crate that defined slices types. (No such crate exists.) The compiler only allows one #[lang(slice)] item to exist, so we have it in liballoc where it can define every method we want slices to have.
So in #![no_std] crates that do not depend on liballoc, slices have no inherent methods. Instead, libcore has a core::slice::SliceExt trait implemented for [T] that has a subset of the methods and needs to be imported into scope to be used.
Background on [u8] methods
#44042 added inherent methods specific to byte slices. They’re also in liballoc, with a new dedicated lang item:
#[lang(slice_u8)]
impl [u8] {
// …
}But they’re not available without liballoc, although they don’t all depend on allocation.
Now
It’d be nice to have some of these [u8] methods without liballoc. The simple thing would be to continue this pattern and add a core::slice::SliceU8Ext trait, but that doesn’t seem like very good design.
Maybe it’s time to revisit SliceExt. Could the “only one #[lang(slice)]” restriction be lifted? Or could we add new core_slice and core_slice_u8 lang items?
CC @eddyb