std::slice::SliceConcatExt impls should rely on AsRef rather than Borrow

[SimonSapin]

HashMap assumes that Borrow implies compatible hashing, which may not be desirable: servo/string-cache#89

[frewsxcv]

A couple RFCs related to SliceConcatExt (for the sake of crosslinking):

• Implement SliceConcatExt for any iterable of string slices, not just Slice and Vec rfcs#1137
• Remove SliceConcatExt, add them as methods on [T]. rfcs#1141

[bluss]

See discussion on #25162 why it was changed to Borrow

[steveklabnik]

Yes, @aturon @alexcrichton , is this actually intended? Seems so

[steveklabnik]

/cc @rust-lang/libs

[Gankra]

To be clear: Almost the entire reason for Borrow to exist is to have "AsRef where Hash/Eq/Ord are expected to hold". (the rest of the reason is differing blanket impls in a world without specialization)

(not clear on what @SimonSapin meant with "may not be desirable")

[alexcrichton]

Yes this was switched to Borrow from AsRef as @bluss pointed out due to coherence issues. Whether or not this is desirable we cannot switch to AsRef today, so I'm going to close this as working as intended.

[SimonSapin]

In string-cache we have:

#[derive(PartialEq, Eq, Hash)]
struct Atom { magic: u64 }
impl Deref for Atom { Target = str; ... }

The whole point of this library is to make Atom::eq fast. While we’re at it, we make Atom::hash fast in the same way. (That is, we only compare/hash the u64 value, not the str’s bytes.) The rest of the library ensures that *atom_1 == *atom_2 if and only if atom_1.magic == atom_2.magic.

To make make Atom::hash fast, we make it not consistent with str::hash. Therefore, Atom should not implement Borrow<str>.

SliceConcatExt however does not rely on hashing. Being able to use it on atoms would be nice.