[u8] methods in libcore?

[SimonSapin]

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

[eddyb]

Ideally none of this would be done with lang items - maybe if we make inherent impls on builtin types unstable and check them like lang items ("link-time coherence") at the method level, instead of the whole impl - after all, only having methods with the same name conflicts.

[eddyb]

cc @rust-lang/compiler

[SimonSapin]

Fixed in #49698 (with a new lang item).

[SimonSapin]

Wait no. I’m confusing two pull requests, sorry.

[SimonSapin]

#49896 fixes this.