Tracking issue for `slice_concat_ext` stabilization

[aturon]

The SliceConcatExt trait offers methods concat and join on slices. For somewhat technical reasons, it wasn't possible to make these inherent methods.

The methods themselves are stable, but the trait isn't. However, since the trait is in the prelude, the methods are usable in stable today.

Ideally, the methods would also be available on iterators, but there are performance ramifications for doing so. Impl specialization may help.

[bfrog]

Having just run into needing this today it would be great to see the documentation for this referenced in the Vec docs with some examples

[aturon]

@bfrog agreed. cc @steveklabnik

[steveklabnik]

/cc #29380

[oconnor663]

@aturon just reading along, and I'm curious if you have time to explain: What are the technical reasons you mentioned at the top? Is this related to why the SliceExt trait exists?

[aturon]

@oconnor663

So, the main problem with moving to inherent methods at this point is that the traits provide something akin to method overloading -- both apply to slice types varying only by some bounds (Clone and Borrow). I think originally they were less general, but there was some other holdup to making them inherent, which I no longer recall.

re: SliceExt: the reason for that trait is somewhat obscure. Basically, the std crate ends up re-exporting a number of things from the core crate, but in the case of types like slices, it also wants to add methods of its own. We set things up so that the set of inherent methods for any type in std has to be defined in exactly one of the crates making up std. So core's slices don't have any inherent items, because they're defined in collections. You can find the impl here: http://static.rust-lang.org/doc/master/src/collections/slice.rs.html#160

If you're just using std, you never need to see/work with SliceExt. But if you're using core, the SliceExt trait is how we provide any methods on slices. It's in the core prelude, so you generally don't notice the difference.

... Hope that helps!

[oconnor663]

Good to know :)

[Dr-Emann]

It's kinda annoying to be able to join strings with a str (which can have multiple chars), but joining a slice of slices, you can only join with a single element.

e.g.

let v = vec!["1", "2", "3"];
v.join(", ")

works, but

let v: Vec<&[u8]> = vec![b"1", b"2", b"3"];
v.join(b", ") // Error: expected u8, found array of 2 elements
v.join(&b',') // works, but is missing the space char

doesn't work

[leodasvacas]

I tried making the methods inherent with separate inherent impls. But we can't have multiple inherent impls for a primitive. I got the error:

"only a single inherent implementation marked with #[lang = "slice"] is allowed for the [T] primitive"

This is known of course, the issue is #32631.

[SimonSapin]

@leodasvacas I think you mean multiple impl Type {…} blocks, but that’s not the main issue. We can add new methods in the existing impl blocks. However in this case, for example <&[String]>::concat and <&[Vec<T>]>::concat end up being the same method, so a helper trait would still be needed to generalize over both cases.

The libs team discussed this and consensus was to add #[doc(hidden)] to the deprecated (but stable) connect method, but make no further changes or stabilize anything at the moment. Inherent methods with a new helper trait doesn’t seem much better than the current trait methods, and still wouldn’t help with joining/concatenating iterators without first collecting into an intermediate Vec.

Design proposals to generalize this functionality to iterators are welcome.

[sanmai-NL]

The methods themselves are stable, but the trait isn't. However, since the trait is in the prelude, the methods are usable in stable today.

Does this mean concat() isn’t usable in a no_std module with explicit std imports and without the slice_concat_ext unstable feature enabled?

[SimonSapin]

@sanmai-NL That is correct. (Modulo #15702, which is a bug and not considered part of the stability promise.)

[BurntSushi]

Does there exist a path to stabilizing SliceConcatExt? Are there any specific outstanding issues associated with it? The specific use case I have for it is that I'd like for it to be able to work on other string types. e.g.,

impl<S: Borrow<BStr>> SliceConcatExt for [S] {
    type Output = BString;
    // ...
}

The work-around is to define a separate trait that is probably identical to SliceConcatExt, but in my crate. But that means users won't benefit from having it in the prelude.