New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for `slice_concat_ext` stabilization #27747

Open
aturon opened this Issue Aug 12, 2015 · 11 comments

Comments

Projects
None yet
9 participants
@aturon
Member

aturon commented Aug 12, 2015

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

This comment has been minimized.

bfrog commented Nov 16, 2015

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

This comment has been minimized.

Member

aturon commented Nov 18, 2015

@bfrog agreed. cc @steveklabnik

@steveklabnik

This comment has been minimized.

Member

steveklabnik commented Nov 18, 2015

/cc #29380

@oconnor663

This comment has been minimized.

Contributor

oconnor663 commented Jan 23, 2016

@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

This comment has been minimized.

Member

aturon commented Feb 2, 2016

@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

This comment has been minimized.

Contributor

oconnor663 commented Feb 2, 2016

Good to know :)

@Dr-Emann

This comment has been minimized.

Dr-Emann commented Apr 17, 2017

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

This comment has been minimized.

Contributor

leodasvacas commented Sep 12, 2017

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

This comment has been minimized.

Contributor

SimonSapin commented Apr 1, 2018

@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

This comment has been minimized.

sanmai-NL commented Sep 6, 2018

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

This comment has been minimized.

Contributor

SimonSapin commented Sep 6, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment