Somebody has to account for trait implementations in stabilization system first to make it happen. Currently, trait implementations for stable types (in std) are insta-stable. There is no way to annotation unstable attribute for them.
1 Like
And neither did I. But still @ibraheemdev's remark is valid. The current situation is just inconsistent. My position is that adding an new trait representing concatenation (for both strings and collections) is the correct way to go. Whether this trait should be associated to a sigil or not can arguably be challenged and I do not have any strong opinion. But, with or without it, the additional trait would certainly make things better than the status quo.
1 Like
FWIW, in my corner of academia, ++ is well-established notation for concatenation. But that corner might be rather tiny. 
8 Likes
Would a Concat trait mutate the caller or return an Output?
Concatenation is already handled well enough by the Extend trait (which both String and Vec<_> implement), so I see no reason to add a duplicate trait .
7 Likes
Then let's remove String + &str
1 Like
We can't because that would be a major breaking change, and having warts is not a reason to add more warts to the language.
4 Likes
My main concern is not about adding anything, it is about removing things that does not make sense because they are highly confusing, in particular for beginners. Aren't editions the occasion for major breaking changes ?
Rust has strong backwards compatibility guarantees, so major breaking changes are only acceptable when they are fix a soundness hole (safety bugs). This doesn't cover fixing confusing API choices or just plain bad APIs. This is part of the reason why it's so hard to get anything into std.
5 Likes
Maybe we could start with a clippy lint?
3 Likes
This is certainly wrong. Editions have added new keywords. Which is certainly a major breaking change.
What about marking the impl as deprecated?
A crate can and needs to specify the edition it targets which means adding a new edition is not a breaking change. The difference between editions and the stdlib is that crates that targets different editions can coexist in the same dependency tree, however the stdlib is only one.
Already answered:
6 Likes
Yes so what ? A crate that target Rust 2021 could be prevented from using String + &str. The point is not if it is possible today but that it could be made possible
Has there been any previous discussions about deprecating trait implementations?
1 Like
Nope.
I think generalizing about editions is a tad premature, but I'd definitely support the narrower viewpoint of what editions are for.
As far as &str + &str being confusing for beginners motivating deprecation, I would agree, but it also motivates having great error messages and
42 | println!("{}", "hello " + "world")
| -------- ^ ------- &str
| | |
| | `+` cannot be used to concatenate two `&str` strings
| &str
|
help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left
|
42 | println!("{}", "hello ".to_owned() + "world")
| ^^^^^^^^^^^^^^^^^^^
seems reasonably beginner friendly.
5 Likes
Hmm, IDK, the error message contains one incredibly long line and also it feels like a period is missing at the end. Maybe one should open an issue about this 
@gbutler, @SkiFire13 : I think we have a misunderstanding in the terminology. A change of edition might not create a breaking change in the Rust ecosystem, but this is certainly a breaking change in the language. Rust 2015 and Rust 2018 are incompatible dialects. That the compiler can handle both of them and allow mixed crates to interact is a great thing but this does not change this latter fact. Rust 2021 could invalidate String + &str with same philosophy and this would not break the ecosystem. The fact it is impossible today is not the point. The point is "would it be worth it to make it possible in the future?"
What if the 2021 crate expect a T: Add<&str> and a 2018 crate passes a String? Or are you just suggesting to special case the syntax for those types?
1 Like