`Borrow` and `AsRef` are redundant

[nwin]

These traits have exactly the same signature, both are stable and both should be implemented by the same types. One of them should go.

Furthermore AsRef is not implemented by Box etc…

[aturon]

There are a few really important differences:

• Borrow is used by data structures like HashMap and BTreeMap which assume that the result of hashing or ordering based on owned and borrowed values is the same. But there are many AsRef conversions for which this isn't true. So in general, Borrow should be implemented for fewer types than AsRef, because it makes stronger guarantees.
• Borrow provides a blanket implementation T: Borrow<T>, which is essential for making the above collections work well. AsRef provides a different blanket implementation, basically &T: AsRef<U> whenever T: AsRef<U>, which is important for APIs like fs::open that can use a simpler and more flexible signature as a result. You can't have both blanket implementations due to coherence, so each trait is making the choice that's appropriate for its use case.

This should be better documented, but there's definitely a reason that things are set up this way.

As to AsRef on Box and friends, the initial implementations were somewhat minimal, and we've been adding more over time.

I'm going to close this issue for now, since the traits are not in fact redundant. But it may be worth opening a separate issue for improved documentation and missing impls on AsRef.

[frewsxcv]

For the sake of cross-posting, I just asked this same question in Discourse without knowing this Issue existed.

[quadrupleslap]

Still not properly documented (I think.)

Edit: The only explanation I can find is on the AsRef page and it's much more vague than @aturon's amazing explanation here.

[steveklabnik]

https://doc.rust-lang.org/book/first-edition/borrow-and-asref.html exists, but it's not going to in the second edition

[prasannavl]

@aturon - Thanks for a better explanation - However from what I understand the only place where Borrow really differs is while borrowing a reference for hashing. So would it not make sense to have the trait be AsHashableRef (or something similar) and method be as_hashable_ref or something similar? Hopefully some one else can come up with a shorter name that makes sense.

It is rather verbose - but it's intentions are much more clear. Borrow is just confusing in the context.

PS: I could be wrong, but my brain is likely misleading me into thinking I have good understanding after reading the above statement, but I'm not entirely sure if I'm clear on the kind of consequences on implementing one over the other would cause. Would be better if there are side-by-side comparisons of both, in the documentation to express it clearly.

[prasannavl]

Ah. Alright, I realize I was wrong - and my above statement is incorrect.

Finally, this was one only post that provided the most sensible documentation so far:
#44868

Thanks to @stjepang for this.

PS: All other documentation including the above comment just focuses so much only hasing - it still doesn't provide a complete picture and possibly misleading - even though it's right.

[partim]

I’m not sure if this is the best place to discuss this, but as part of working on #44868, I’d like to verify the precise guarantees made by Borrow. My feeling is that the set of traits for which, if they are implemented, both types must exhibit identical behavior, is larger than just the comparison traits.

In other words: Has Borrow been devised exclusively for collections or is there wider use cases?