Add joining slices of slices with a slice separator, not just a single item #62528

SimonSapin · 2019-07-09T12:44:03Z

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.

This turns out to be fixable, with some possible inference regressions.

TL;DR

Related trait(s) are unstable and tracked at #27747, but the [T]::join method that is being extended here is already stable.

Example use of the new insta-stable functionality:

let nested: Vec<Vec<Foo>> = /* … */;
let separator: &[Foo] = /* … */;  // Previously: could only be a single &Foo
nested.join(separator)

Complete API affected by this PR, after changes:

impl<T> [T] {
    pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output
        where Self: Concat<Item>
    {
        Concat::concat(self)
    }
    pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output
        where Self: Join<Separator>
    {
        Join::join(self, sep)
    }
}

// The `Item` parameter is only useful for the the slice-of-slices impl.
pub trait Concat<Item: ?Sized> {
    type Output;
    fn concat(slice: &Self) -> Self::Output;
}

pub trait Join<Separator> {
    type Output;
    fn join(slice: &Self, sep: Separator) -> Self::Output;
}

impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] {
    type Output = Vec<T>;
}

impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] {
    type Output = Vec<T>;
}

// New functionality here!
impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] {
    type Output = Vec<T>;
}

impl<S: Borrow<str>> Concat<str> for [S] {
    type Output = String;
}

impl<S: Borrow<str>> Join<&'_ str> for [S] {
    type Output = String;
}

Details

After #62403 but before this PR, the API is:

impl<T> [T] {
    pub fn concat<Separator: ?Sized>(&self) -> T::Output
        where T: SliceConcat<Separator>
    {
        SliceConcat::concat(self)
    }

    pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output
        where T: SliceConcat<Separator>
    {
        SliceConcat::join(self, sep)
    }
}

pub trait SliceConcat<Separator: ?Sized>: Sized {
    type Output;
    fn concat(slice: &[Self]) -> Self::Output;
    fn join(slice: &[Self], sep: &Separator) -> Self::Output;
}

impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V {
    type Output = Vec<T>;
}

impl<S: Borrow<str>> SliceConcat<str> for S {
    type Output = String;
}

By adding a trait impl we should be able to accept a slice of T as the separator, as an alternative to a single T value.

In a some_slice.join(some_separator) call, trait resolution will pick an impl or the other based on the type of some_separator. In some_slice.concat() however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to concat isn’t great.

The solution to that is splitting the SliceConcat trait into two Concat and Join traits, one for each eponymous method. Only Join would gain a new impl, so that some_slice.concat() would not become ambiguous.

Now, at the trait level the Concat trait does not need a Separator parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore:

error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates
  --> src/liballoc/slice.rs:608:6
    |
608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] {
    |      ^ unconstrained type parameter

This makes sense: if [V]::concat is a method that is itself not generic, then its return type (which is the Concat::Output associated type) needs to be determined based on solely V. And although there is no such type in the standard library, there is nothing stopping another crate from defining a V type that implements both Borrow<[Foo]> and Borrow<[Bar]>. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine T.

This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement Concat for [&'_ [T]] and Concat for [Vec<T>] etc. However this aspect of [V]::concat is already stable, so we’re stuck with it.

The solution is to keep a dummy type parameter on the Concat trait. That way, if a type has multiple Borrow<[_]> impls, it’ll end up with multiple corresponding Concat<_> impls.

In impl<S: Borrow<str>> Concat<str> for [S], the second occurrence of str is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes.

Joining strings with `char`

For symmetry I also tried adding this impl (because why not):

impl<S: Borrow<str>> Join<char> for [S] {
    type Output = String;
}

This immediately caused an inference regression in a dependency of rustc:

error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied
   --> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37
    |
595 |             row.push_str(&desc_rows.join(&desc_sep));
    |                                     ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String`
    |
    = help: the following implementations were found:
              <std::string::String as std::borrow::Borrow<str>>
    = note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]`

In the context of this code, two facts are known:

desc_rows is a Vec<String>
desc_sep is a String

Previously the first fact alone reduces the resolution of join to only one solution, where its argument it expected to be &str. Then, &String is coerced to &str.

With the new Join impl, the first fact leavs two applicable impls where the separator can be either &str or char. But &String is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution.

I have not included this new impl in this PR. It’s still possible to add later, but the getopts breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))

The &* part of that last code snippet is another case of the same issue: encode_utf8 returns &mut str which can be coerced to &str, but isn’t when trait resolution is ambiguous.

…e item

rust-highfive · 2019-07-09T12:44:14Z

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

SimonSapin · 2019-07-09T12:47:00Z

While the SliceConcat trait is unstable, this PR includes new insta-stable functionality:

let nested: Vec<Vec<Foo>> = /* … */;
let separator: &[Foo] = /* … */;  // Previously: could only be a single &Foo
nested.join(separator)

@rfcbot fcp merge

Because there may be inference regressions, we may want to do a Crater run:

@bors try

bors · 2019-07-09T12:47:11Z

⌛ Trying commit b62a77b with merge 13fab3f0e4a2da67c10531e8bcafaf6a30763a17...

rfcbot · 2019-07-09T13:06:50Z

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

bors · 2019-07-09T15:27:57Z

☀️ Try build successful - checks-azure, checks-travis
Build commit: 13fab3f0e4a2da67c10531e8bcafaf6a30763a17

src/liballoc/slice.rs

src/liballoc/str.rs

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

SimonSapin · 2019-07-09T16:21:08Z

@craterbot run mode=check-only

craterbot · 2019-07-09T16:21:10Z

👌 Experiment pr-62528 created and queued.
🤖 Automatically detected try build 13fab3f0e4a2da67c10531e8bcafaf6a30763a17
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

rfcbot · 2019-07-12T04:18:16Z

🔔 This is now entering its final comment period, as per the review above. 🔔

craterbot · 2019-07-13T11:43:11Z

🚧 Experiment pr-62528 is now running on agent aws-2.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2019-07-13T11:43:12Z

🚨 Experiment pr-62528 has encountered an error: docker is not running
🛠️ If the error is fixed use the retry command.

🆘 Can someone from the infra team check in on this? @rust-lang/infra
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Add joining slices of slices with a slice separator, not just a single item rust-lang#27747 (comment) > 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. This turns out to be fixable, with some possible inference regressions. # TL;DR Related trait(s) are unstable and tracked at rust-lang#27747, but the `[T]::join` method that is being extended here is already stable. Example use of the new insta-stable functionality: ```rust let nested: Vec<Vec<Foo>> = /* … */; let separator: &[Foo] = /* … */; // Previously: could only be a single &Foo nested.join(separator) ``` Complete API affected by this PR, after changes: ```rust impl<T> [T] { pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output where Self: Concat<Item> { Concat::concat(self) } pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output where Self: Join<Separator> { Join::join(self, sep) } } // The `Item` parameter is only useful for the the slice-of-slices impl. pub trait Concat<Item: ?Sized> { type Output; fn concat(slice: &Self) -> Self::Output; } pub trait Join<Separator> { type Output; fn join(slice: &Self, sep: Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] { type Output = Vec<T>; } impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] { type Output = Vec<T>; } // New functionality here! impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] { type Output = Vec<T>; } impl<S: Borrow<str>> Concat<str> for [S] { type Output = String; } impl<S: Borrow<str>> Join<&'_ str> for [S] { type Output = String; } ``` # Details After rust-lang#62403 but before this PR, the API is: ```rust impl<T> [T] { pub fn concat<Separator: ?Sized>(&self) -> T::Output where T: SliceConcat<Separator> { SliceConcat::concat(self) } pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output where T: SliceConcat<Separator> { SliceConcat::join(self, sep) } } pub trait SliceConcat<Separator: ?Sized>: Sized { type Output; fn concat(slice: &[Self]) -> Self::Output; fn join(slice: &[Self], sep: &Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V { type Output = Vec<T>; } impl<S: Borrow<str>> SliceConcat<str> for S { type Output = String; } ``` By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value. In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great. The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous. Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore: ```rust error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> src/liballoc/slice.rs:608:6 | 608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] { | ^ unconstrained type parameter ``` This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`. This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it. The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls. In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes. # Joining strings with `char` For symmetry I also tried adding this impl (because why not): ```rust impl<S: Borrow<str>> Join<char> for [S] { type Output = String; } ``` This immediately caused an inference regression in a dependency of rustc: ```rust error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied --> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37 | 595 | row.push_str(&desc_rows.join(&desc_sep)); | ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String` | = help: the following implementations were found: <std::string::String as std::borrow::Borrow<str>> = note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]` ``` In the context of this code, two facts are known: * `desc_rows` is a `Vec<String>` * `desc_sep` is a `String` Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`. With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution. I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))` The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.

@ghost

Rollup of 11 pull requests Successful merges: - #62261 (Take substs into account in `conservative_is_privately_uninhabited`) - #62528 (Add joining slices of slices with a slice separator, not just a single item) - #62738 (Remove uses of mem::uninitialized from std::sys::cloudabi) - #62784 (Add riscv32i-unknown-none-elf target) - #62808 (Revert "Disable stack probing for gnux32.") - #62814 (add support for hexagon-unknown-linux-musl) - #62822 (Improve some pointer-related documentation) - #62890 (Normalize use of backticks in compiler messages for libsyntax/*) - #62901 (cleanup: Remove `extern crate serialize as rustc_serialize`s) - #62905 (Normalize use of backticks in compiler messages for doc) - #62908 (normalize use of backticks for compiler messages in remaining modules) Failed merges: r? @ghost

Add joining slices of slices with a slice separator, not just a single item rust-lang#27747 (comment) > 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. This turns out to be fixable, with some possible inference regressions. # TL;DR Related trait(s) are unstable and tracked at rust-lang#27747, but the `[T]::join` method that is being extended here is already stable. Example use of the new insta-stable functionality: ```rust let nested: Vec<Vec<Foo>> = /* … */; let separator: &[Foo] = /* … */; // Previously: could only be a single &Foo nested.join(separator) ``` Complete API affected by this PR, after changes: ```rust impl<T> [T] { pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output where Self: Concat<Item> { Concat::concat(self) } pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output where Self: Join<Separator> { Join::join(self, sep) } } // The `Item` parameter is only useful for the the slice-of-slices impl. pub trait Concat<Item: ?Sized> { type Output; fn concat(slice: &Self) -> Self::Output; } pub trait Join<Separator> { type Output; fn join(slice: &Self, sep: Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] { type Output = Vec<T>; } impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] { type Output = Vec<T>; } // New functionality here! impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] { type Output = Vec<T>; } impl<S: Borrow<str>> Concat<str> for [S] { type Output = String; } impl<S: Borrow<str>> Join<&'_ str> for [S] { type Output = String; } ``` # Details After rust-lang#62403 but before this PR, the API is: ```rust impl<T> [T] { pub fn concat<Separator: ?Sized>(&self) -> T::Output where T: SliceConcat<Separator> { SliceConcat::concat(self) } pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output where T: SliceConcat<Separator> { SliceConcat::join(self, sep) } } pub trait SliceConcat<Separator: ?Sized>: Sized { type Output; fn concat(slice: &[Self]) -> Self::Output; fn join(slice: &[Self], sep: &Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V { type Output = Vec<T>; } impl<S: Borrow<str>> SliceConcat<str> for S { type Output = String; } ``` By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value. In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great. The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous. Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore: ```rust error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> src/liballoc/slice.rs:608:6 | 608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] { | ^ unconstrained type parameter ``` This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`. This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it. The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls. In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes. # Joining strings with `char` For symmetry I also tried adding this impl (because why not): ```rust impl<S: Borrow<str>> Join<char> for [S] { type Output = String; } ``` This immediately caused an inference regression in a dependency of rustc: ```rust error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied --> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37 | 595 | row.push_str(&desc_rows.join(&desc_sep)); | ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String` | = help: the following implementations were found: <std::string::String as std::borrow::Borrow<str>> = note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]` ``` In the context of this code, two facts are known: * `desc_rows` is a `Vec<String>` * `desc_sep` is a `String` Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`. With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution. I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))` The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.

@ghost

Rollup of 10 pull requests Successful merges: - rust-lang#60938 (rustdoc: make #[doc(include)] relative to the containing file) - rust-lang#61890 (Fix some sanity checks) - rust-lang#62261 (Take substs into account in `conservative_is_privately_uninhabited`) - rust-lang#62528 (Add joining slices of slices with a slice separator, not just a single item) - rust-lang#62735 (Turn `#[global_allocator]` into a regular attribute macro) - rust-lang#62801 (Remove support for -Zlower-128bit-ops) - rust-lang#62808 (Revert "Disable stack probing for gnux32.") - rust-lang#62819 (Display name of crate requiring rustc_private in error messages.) - rust-lang#62904 (Disable d32 on armv6 hf targets) - rust-lang#62907 (Initialize the MSP430 AsmParser) Failed merges: r? @ghost

Add joining slices of slices with a slice separator, not just a single item rust-lang#27747 (comment) > 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. This turns out to be fixable, with some possible inference regressions. # TL;DR Related trait(s) are unstable and tracked at rust-lang#27747, but the `[T]::join` method that is being extended here is already stable. Example use of the new insta-stable functionality: ```rust let nested: Vec<Vec<Foo>> = /* … */; let separator: &[Foo] = /* … */; // Previously: could only be a single &Foo nested.join(separator) ``` Complete API affected by this PR, after changes: ```rust impl<T> [T] { pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output where Self: Concat<Item> { Concat::concat(self) } pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output where Self: Join<Separator> { Join::join(self, sep) } } // The `Item` parameter is only useful for the the slice-of-slices impl. pub trait Concat<Item: ?Sized> { type Output; fn concat(slice: &Self) -> Self::Output; } pub trait Join<Separator> { type Output; fn join(slice: &Self, sep: Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] { type Output = Vec<T>; } impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] { type Output = Vec<T>; } // New functionality here! impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] { type Output = Vec<T>; } impl<S: Borrow<str>> Concat<str> for [S] { type Output = String; } impl<S: Borrow<str>> Join<&'_ str> for [S] { type Output = String; } ``` # Details After rust-lang#62403 but before this PR, the API is: ```rust impl<T> [T] { pub fn concat<Separator: ?Sized>(&self) -> T::Output where T: SliceConcat<Separator> { SliceConcat::concat(self) } pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output where T: SliceConcat<Separator> { SliceConcat::join(self, sep) } } pub trait SliceConcat<Separator: ?Sized>: Sized { type Output; fn concat(slice: &[Self]) -> Self::Output; fn join(slice: &[Self], sep: &Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V { type Output = Vec<T>; } impl<S: Borrow<str>> SliceConcat<str> for S { type Output = String; } ``` By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value. In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great. The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous. Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore: ```rust error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> src/liballoc/slice.rs:608:6 | 608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] { | ^ unconstrained type parameter ``` This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`. This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it. The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls. In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes. # Joining strings with `char` For symmetry I also tried adding this impl (because why not): ```rust impl<S: Borrow<str>> Join<char> for [S] { type Output = String; } ``` This immediately caused an inference regression in a dependency of rustc: ```rust error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied --> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37 | 595 | row.push_str(&desc_rows.join(&desc_sep)); | ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String` | = help: the following implementations were found: <std::string::String as std::borrow::Borrow<str>> = note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]` ``` In the context of this code, two facts are known: * `desc_rows` is a `Vec<String>` * `desc_sep` is a `String` Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`. With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution. I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))` The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.

@ghost

Rollup of 13 pull requests Successful merges: - rust-lang#60938 (rustdoc: make #[doc(include)] relative to the containing file) - rust-lang#61890 (Fix some sanity checks) - rust-lang#62084 (allow clippy::unreadable_literal in unicode tables) - rust-lang#62261 (Take substs into account in `conservative_is_privately_uninhabited`) - rust-lang#62528 (Add joining slices of slices with a slice separator, not just a single item) - rust-lang#62735 (Turn `#[global_allocator]` into a regular attribute macro) - rust-lang#62801 (Remove support for -Zlower-128bit-ops) - rust-lang#62808 (Revert "Disable stack probing for gnux32.") - rust-lang#62822 (Improve some pointer-related documentation) - rust-lang#62904 (Disable d32 on armv6 hf targets) - rust-lang#62907 (Initialize the MSP430 AsmParser) - rust-lang#62921 (Add method disambiguation help for trait implementation) - rust-lang#62942 (Use match ergonomics in Condvar documentation) Failed merges: r? @ghost

Add joining slices of slices with a slice separator, not just a single item rust-lang#27747 (comment) > 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. This turns out to be fixable, with some possible inference regressions. # TL;DR Related trait(s) are unstable and tracked at rust-lang#27747, but the `[T]::join` method that is being extended here is already stable. Example use of the new insta-stable functionality: ```rust let nested: Vec<Vec<Foo>> = /* … */; let separator: &[Foo] = /* … */; // Previously: could only be a single &Foo nested.join(separator) ``` Complete API affected by this PR, after changes: ```rust impl<T> [T] { pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output where Self: Concat<Item> { Concat::concat(self) } pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output where Self: Join<Separator> { Join::join(self, sep) } } // The `Item` parameter is only useful for the the slice-of-slices impl. pub trait Concat<Item: ?Sized> { type Output; fn concat(slice: &Self) -> Self::Output; } pub trait Join<Separator> { type Output; fn join(slice: &Self, sep: Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] { type Output = Vec<T>; } impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] { type Output = Vec<T>; } // New functionality here! impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] { type Output = Vec<T>; } impl<S: Borrow<str>> Concat<str> for [S] { type Output = String; } impl<S: Borrow<str>> Join<&'_ str> for [S] { type Output = String; } ``` # Details After rust-lang#62403 but before this PR, the API is: ```rust impl<T> [T] { pub fn concat<Separator: ?Sized>(&self) -> T::Output where T: SliceConcat<Separator> { SliceConcat::concat(self) } pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output where T: SliceConcat<Separator> { SliceConcat::join(self, sep) } } pub trait SliceConcat<Separator: ?Sized>: Sized { type Output; fn concat(slice: &[Self]) -> Self::Output; fn join(slice: &[Self], sep: &Separator) -> Self::Output; } impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V { type Output = Vec<T>; } impl<S: Borrow<str>> SliceConcat<str> for S { type Output = String; } ``` By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value. In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great. The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous. Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore: ```rust error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> src/liballoc/slice.rs:608:6 | 608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] { | ^ unconstrained type parameter ``` This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`. This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it. The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls. In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes. # Joining strings with `char` For symmetry I also tried adding this impl (because why not): ```rust impl<S: Borrow<str>> Join<char> for [S] { type Output = String; } ``` This immediately caused an inference regression in a dependency of rustc: ```rust error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied --> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37 | 595 | row.push_str(&desc_rows.join(&desc_sep)); | ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String` | = help: the following implementations were found: <std::string::String as std::borrow::Borrow<str>> = note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]` ``` In the context of this code, two facts are known: * `desc_rows` is a `Vec<String>` * `desc_sep` is a `String` Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`. With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution. I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))` The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.

@ghost

Rollup of 15 pull requests Successful merges: - #60066 (Stabilize the type_name intrinsic in core::any) - #60938 (rustdoc: make #[doc(include)] relative to the containing file) - #61884 (Stablize Euclidean Modulo (feature euclidean_division)) - #61890 (Fix some sanity checks) - #62528 (Add joining slices of slices with a slice separator, not just a single item) - #62707 (Add tests for overlapping explicitly dropped locals in generators) - #62735 (Turn `#[global_allocator]` into a regular attribute macro) - #62822 (Improve some pointer-related documentation) - #62887 (Make the parser TokenStream more resilient after mismatched delimiter recovery) - #62921 (Add method disambiguation help for trait implementation) - #62930 (Add test for #51559) - #62942 (Use match ergonomics in Condvar documentation) - #62977 (Fix inconsistent highlight blocks.) - #62978 (Remove `cfg(bootstrap)` code for array implementations) - #62981 (Add note suggesting to borrow a String argument to find) Failed merges: - #62964 (clarify and unify some type test names) r? @ghost

Pkgsrc changes: * Adapt to the move of the implementation of random numbers. * Remove patch which is no longer relevant (Signals.inc) * Cross-build currently fails due to the still unresolved rust-lang/rust#62558, so bootstrap kits for 1.38.0 have to be built natively, and will follow shortly. * Bump bootstrap requirements to 1.37.0 except for armv7-unknown-netbsd-eabihf which I've neither managed to cross-build nor build natively. Upstream changes: Version 1.38.0 (2019-09-26) ========================== Language -------- - [The `#[global_allocator]` attribute can now be used in submodules.][62735] - [The `#[deprecated]` attribute can now be used on macros.][62042] Compiler -------- - [Added pipelined compilation support to `rustc`.][62766] This will improve compilation times in some cases. For further information please refer to the [_"Evaluating pipelined rustc compilation"_][pipeline-internals] thread. - [Added tier 3\* support for the `aarch64-uwp-windows-msvc`, `i686-uwp-windows-gnu`, `i686-uwp-windows-msvc`, `x86_64-uwp-windows-gnu`, and `x86_64-uwp-windows-msvc` targets.][60260] - [Added tier 3 support for the `armv7-unknown-linux-gnueabi` and `armv7-unknown-linux-musleabi` targets.][63107] - [Added tier 3 support for the `hexagon-unknown-linux-musl` target.][62814] - [Added tier 3 support for the `riscv32i-unknown-none-elf` target.][62784] \* Refer to Rust's [platform support page][forge-platform-support] for more information on Rust's tiered platform support. Libraries --------- - [`ascii::EscapeDefault` now implements `Clone` and `Display`.][63421] - [Derive macros for prelude traits (e.g. `Clone`, `Debug`, `Hash`) are now available at the same path as the trait.][63056] (e.g. The `Clone` derive macro is available at `std::clone::Clone`). This also makes all built-in macros available in `std`/`core` root. e.g. `std::include_bytes!`. - [`str::Chars` now implements `Debug`.][63000] - [`slice::{concat, connect, join}` now accepts `&[T]` in addition to `&T`.][62528] - [`*const T` and `*mut T` now implement `marker::Unpin`.][62583] - [`Arc<[T]>` and `Rc<[T]>` now implement `FromIterator<T>`.][61953] - [Added euclidean remainder and division operations (`div_euclid`, `rem_euclid`) to all numeric primitives.][61884] Additionally `checked`, `overflowing`, and `wrapping` versions are available for all integer primitives. - [`thread::AccessError` now implements `Clone`, `Copy`, `Eq`, `Error`, and `PartialEq`.][61491] - [`iter::{StepBy, Peekable, Take}` now implement `DoubleEndedIterator`.][61457] Stabilized APIs --------------- - [`<*const T>::cast`] - [`<*mut T>::cast`] - [`Duration::as_secs_f32`] - [`Duration::as_secs_f64`] - [`Duration::div_duration_f32`] - [`Duration::div_duration_f64`] - [`Duration::div_f32`] - [`Duration::div_f64`] - [`Duration::from_secs_f32`] - [`Duration::from_secs_f64`] - [`Duration::mul_f32`] - [`Duration::mul_f64`] - [`any::type_name`] Cargo ----- - [Added pipelined compilation support to `cargo`.][cargo/7143] - [You can now pass the `--features` option multiple times to enable multiple features.][cargo/7084] Misc ---- - [`rustc` will now warn about some incorrect uses of `mem::{uninitialized, zeroed}` that are known to cause undefined behaviour.][63346] Compatibility Notes ------------------- - Unfortunately the [`x86_64-unknown-uefi` platform can not be built][62785] with rustc 1.39.0. - The [`armv7-unknown-linux-gnueabihf` platform is also known to have issues][62896] for certain crates such as libc. [60260]: rust-lang/rust#60260 [61457]: rust-lang/rust#61457 [61491]: rust-lang/rust#61491 [61884]: rust-lang/rust#61884 [61953]: rust-lang/rust#61953 [62042]: rust-lang/rust#62042 [62528]: rust-lang/rust#62528 [62583]: rust-lang/rust#62583 [62735]: rust-lang/rust#62735 [62766]: rust-lang/rust#62766 [62784]: rust-lang/rust#62784 [62785]: rust-lang/rust#62785 [62814]: rust-lang/rust#62814 [62896]: rust-lang/rust#62896 [63000]: rust-lang/rust#63000 [63056]: rust-lang/rust#63056 [63107]: rust-lang/rust#63107 [63346]: rust-lang/rust#63346 [63421]: rust-lang/rust#63421 [cargo/7084]: rust-lang/cargo#7084 [cargo/7143]: rust-lang/cargo#7143 [`<*const T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`<*mut T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`Duration::as_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32 [`Duration::as_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f64 [`Duration::div_duration_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f32 [`Duration::div_duration_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f64 [`Duration::div_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f32 [`Duration::div_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f64 [`Duration::from_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f32 [`Duration::from_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f64 [`Duration::mul_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f32 [`Duration::mul_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f64 [`any::type_name`]: https://doc.rust-lang.org/std/any/fn.type_name.html [forge-platform-support]: https://forge.rust-lang.org/platform-support.html [pipeline-internals]: https://internals.rust-lang.org/t/evaluating-pipelined-rustc-compilation/10199

SimonSapin added 4 commits July 9, 2019 11:45

Remove obsolete “should not have to exist” reasons

5397dfc

Split the SliceConcat trait into Concat and Join

01d93bf

Take separator by value in [T]::join

283f676

Add joining slices of slices with a slice separator, not just a singl…

b62a77b

…e item

SimonSapin added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jul 9, 2019

rust-highfive assigned dtolnay Jul 9, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 9, 2019

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jul 9, 2019

This was referenced Jul 9, 2019

Account for coercions in trait resolution? #62530

Closed

Tracking issue for slice_concat_ext stabilization #27747

Closed

Centril reviewed Jul 9, 2019

View reviewed changes

src/liballoc/slice.rs Outdated Show resolved Hide resolved

src/liballoc/slice.rs Outdated Show resolved Hide resolved

src/liballoc/str.rs Outdated Show resolved Hide resolved

SimonSapin and others added 3 commits July 9, 2019 18:19

Update src/liballoc/slice.rs

d0635ee

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

Update src/liballoc/slice.rs

bbc9366

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

Update src/liballoc/str.rs

5f7768a

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 9, 2019

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jul 12, 2019

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jul 12, 2019

Centril mentioned this pull request Jul 23, 2019

Rollup of 13 pull requests #62920

Closed

Centril mentioned this pull request Jul 24, 2019

Rollup of 11 pull requests #62923

Closed

Centril mentioned this pull request Jul 24, 2019

Rollup of 10 pull requests #62936

Closed

Centril mentioned this pull request Jul 24, 2019

Rollup of 13 pull requests #62960

Closed

Centril mentioned this pull request Jul 25, 2019

Rollup of 9 pull requests #62966

Closed

Centril mentioned this pull request Jul 25, 2019

Rollup of 15 pull requests #62990

Merged

bors merged commit 5f7768a into rust-lang:master Jul 26, 2019

SimonSapin deleted the concat branch August 1, 2019 12:10

est31 mentioned this pull request Jul 27, 2022

regression: Join impl for OsStr insufficiently generic #99683

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add joining slices of slices with a slice separator, not just a single item #62528

Add joining slices of slices with a slice separator, not just a single item #62528

SimonSapin commented Jul 9, 2019

rust-highfive commented Jul 9, 2019

SimonSapin commented Jul 9, 2019

bors commented Jul 9, 2019

rfcbot commented Jul 9, 2019 •

edited by dtolnay

Loading

bors commented Jul 9, 2019

SimonSapin commented Jul 9, 2019

craterbot commented Jul 9, 2019

rfcbot commented Jul 12, 2019

craterbot commented Jul 13, 2019

craterbot commented Jul 13, 2019

Add joining slices of slices with a slice separator, not just a single item #62528

Add joining slices of slices with a slice separator, not just a single item #62528

Conversation

SimonSapin commented Jul 9, 2019

TL;DR

Details

Joining strings with char

rust-highfive commented Jul 9, 2019

SimonSapin commented Jul 9, 2019

bors commented Jul 9, 2019

rfcbot commented Jul 9, 2019 • edited by dtolnay Loading

bors commented Jul 9, 2019

SimonSapin commented Jul 9, 2019

craterbot commented Jul 9, 2019

rfcbot commented Jul 12, 2019

craterbot commented Jul 13, 2019

craterbot commented Jul 13, 2019

Joining strings with `char`

rfcbot commented Jul 9, 2019 •

edited by dtolnay

Loading