Commit e4c3883
authored
Rollup merge of #62528 - SimonSapin:concat, r=alexcrichton
Add joining slices of slices with a slice separator, not just a single item
#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 #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 #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.2 files changed
+96
-29
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
494 | 494 | | |
495 | 495 | | |
496 | 496 | | |
497 | | - | |
498 | | - | |
| 497 | + | |
| 498 | + | |
499 | 499 | | |
500 | | - | |
| 500 | + | |
501 | 501 | | |
502 | 502 | | |
503 | 503 | | |
| |||
508 | 508 | | |
509 | 509 | | |
510 | 510 | | |
| 511 | + | |
511 | 512 | | |
512 | 513 | | |
513 | | - | |
514 | | - | |
| 514 | + | |
| 515 | + | |
515 | 516 | | |
516 | | - | |
| 517 | + | |
517 | 518 | | |
518 | 519 | | |
519 | 520 | | |
| |||
528 | 529 | | |
529 | 530 | | |
530 | 531 | | |
531 | | - | |
532 | | - | |
| 532 | + | |
| 533 | + | |
533 | 534 | | |
534 | | - | |
| 535 | + | |
535 | 536 | | |
536 | 537 | | |
537 | 538 | | |
| |||
578 | 579 | | |
579 | 580 | | |
580 | 581 | | |
581 | | - | |
582 | | - | |
| 582 | + | |
| 583 | + | |
| 584 | + | |
| 585 | + | |
| 586 | + | |
| 587 | + | |
| 588 | + | |
| 589 | + | |
| 590 | + | |
| 591 | + | |
| 592 | + | |
| 593 | + | |
| 594 | + | |
| 595 | + | |
| 596 | + | |
| 597 | + | |
| 598 | + | |
| 599 | + | |
| 600 | + | |
| 601 | + | |
| 602 | + | |
| 603 | + | |
| 604 | + | |
| 605 | + | |
| 606 | + | |
| 607 | + | |
| 608 | + | |
| 609 | + | |
| 610 | + | |
583 | 611 | | |
584 | | - | |
| 612 | + | |
585 | 613 | | |
586 | 614 | | |
587 | 615 | | |
588 | 616 | | |
589 | 617 | | |
590 | 618 | | |
591 | | - | |
| 619 | + | |
| 620 | + | |
| 621 | + | |
| 622 | + | |
| 623 | + | |
| 624 | + | |
| 625 | + | |
| 626 | + | |
| 627 | + | |
592 | 628 | | |
593 | 629 | | |
594 | 630 | | |
595 | | - | |
| 631 | + | |
596 | 632 | | |
597 | 633 | | |
598 | | - | |
599 | | - | |
600 | | - | |
601 | | - | |
| 634 | + | |
| 635 | + | |
602 | 636 | | |
603 | 637 | | |
604 | | - | |
| 638 | + | |
605 | 639 | | |
606 | 640 | | |
607 | 641 | | |
608 | 642 | | |
609 | 643 | | |
610 | 644 | | |
611 | 645 | | |
| 646 | + | |
| 647 | + | |
| 648 | + | |
| 649 | + | |
| 650 | + | |
612 | 651 | | |
613 | | - | |
| 652 | + | |
614 | 653 | | |
615 | 654 | | |
616 | 655 | | |
617 | 656 | | |
618 | 657 | | |
619 | | - | |
| 658 | + | |
620 | 659 | | |
621 | 660 | | |
622 | 661 | | |
| |||
628 | 667 | | |
629 | 668 | | |
630 | 669 | | |
| 670 | + | |
| 671 | + | |
| 672 | + | |
| 673 | + | |
| 674 | + | |
| 675 | + | |
| 676 | + | |
| 677 | + | |
| 678 | + | |
| 679 | + | |
| 680 | + | |
| 681 | + | |
| 682 | + | |
| 683 | + | |
| 684 | + | |
| 685 | + | |
| 686 | + | |
| 687 | + | |
| 688 | + | |
| 689 | + | |
| 690 | + | |
| 691 | + | |
| 692 | + | |
631 | 693 | | |
632 | 694 | | |
633 | 695 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
37 | 37 | | |
38 | 38 | | |
39 | 39 | | |
40 | | - | |
| 40 | + | |
41 | 41 | | |
42 | 42 | | |
43 | 43 | | |
| |||
71 | 71 | | |
72 | 72 | | |
73 | 73 | | |
74 | | - | |
75 | | - | |
76 | | - | |
77 | | - | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
78 | 78 | | |
79 | 79 | | |
80 | | - | |
81 | | - | |
| 80 | + | |
| 81 | + | |
82 | 82 | | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
83 | 88 | | |
84 | | - | |
| 89 | + | |
85 | 90 | | |
86 | 91 | | |
87 | 92 | | |
| |||
0 commit comments