FromIterator and Extend Cow for String

[Eh2406]

This is a quick draft to start working on #41351.
I don't think I got the stable attributes correct, but it is good enuf to start a conversation.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @sfackler (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[mrhota]

@Eh2406 can you respond to the comment on the linked issue? Why not impl FromIterator<Borrow<str>> for String?

[codyps]

On the stability attributes: Trait impls are (unfortunately) still insta-stable, they ignore stability attributes.

Edit: oh, and it would really need to be impl<T: Borrow<str>> FromIterator<T> for String to be a reasonable substitution.

[Eh2406]

I'd love to use the more generic version. It will replace all existing impls. Do we just throw out the stability feature and versions?

[Eh2406]

char can not impl Borrow thus the generic does not cover existing stable uses, but rust does not know that it will never impl it so it won't let us have the generic and the specific.

// proposed generic versionimpl<T:Borrow<str>>FromIterator<T>forString{}// existing implsimpl<'a>FromIterator<&'astr>forString{...}// remove, covered by generic implFromIterator<String>forString{...}// remove, covered by generic implFromIterator<char>forString{...}// not covered nor compatible with generic 

[Eh2406]

leaving the impls for char in lead to
conflicting implementations of trait core::iter::FromIterator<char>

[Eh2406]

and if I remove the impls for char it corectly points out that the trait core::borrow::Borrow<str> is not implemented for char. So I don't see how to do this genericly.

[codyps]

hmm, that is a shame about the conflicts. Can specialization be used here to allow this? (And I suppose the follow up is: do we want to use specialization for this case).

[Eh2406]

conflicting implementations but this is my ferst use of specialization. Did I use it wrong?

I have bean testing in other prs so that this direct version says mergeable.

[arielb1]

Thanks for the PR! We'll make sure that @aturon (or someone else) helps you with the specialization and reviews this.

r? @aturon

[aturon]

Specialization can't be used to tackle this problem, because char does not implement the necessary trait (and hence the impl isn't a specialization).

The core problem is as @Eh2406 identified, which is that Rust is trying to defend against a future where char does impl the trait (this happens because char is defined in core while this impl must live in std).

I think this is the best we can do for the time being. Can you update the version numbers on the stability attributes, to 1.19?

Otherwise, r=me.

[Eh2406]

Fixed, rebased, and squashed.

[aturon]

Thanks!

@bors: r+ rollup

[bors]

📌 Commit 0e2571b has been approved by aturon