Binary operator traits with specializable generic implementations

[mzabaluev]

Provide new fallback traits for overloading binary operators, such as DefaultPartialEq, DefaultPartialOrd, DefaultAdd, DefaultAddAssign, etc., with default blanket implementations abstracted over Borrow for built-in and standard library types. This will drastically reduce the number of explicit impl items necessary to cover operator-compatible type pairs. When resolving the implementation for an operator, the compiler will consider the new traits as the second choice after the plain old non-specializable overload traits.

Edited: previous revisions proposed next-gen operator overload traits to replace the Rust 1.0 traits, with a complicated overload resolution rule for backward compatibility.

Rendered view

[mzabaluev]

@withoutboats The compiler will need to be changed to consider the new traits, with a kink in the algorithm. Are you sure T-lang does not apply?

[mzabaluev]

An alternative idea occurred to me: add the new style op traits not as a next-gen replacement for the Rust 1.0 traits, but as fallback generic implementations: the generic impl of OpDefault (not necessarily specializable) would apply when no Op implementation matches the operator.

WDYT?

[RustyYato]

I don't see how this proposal solves the problem with specialization because this looks just like specialization. But only for the specified operator traits and with some new added complexity. Please elaborate on how this improves this situation. If the only difference is that it isn't a breaking change to add a PartialEq2 impl when a PartialEq impl exists, then that is a poor reason to add these traits. What if we wan't to use AsRef in the future, or provide some other way of doing PartialEq, do we need to add PartialEqN (slippery slope argument). This sets a bad precedent.

Yes it is unfortunate that we can't extend String (or other types) in this way, I don't see this as sufficient motivation for such complexity.

[mzabaluev]

@KrishnaSannasi For a real-world example that perhaps illustrates the problem better than the dry motivational prose of my RFC, please take a look at this long list of PartialEq/PartialOrd impls for Bytes and BytesMut. Please suggest a way to resolve this tedium with generic default implementations that: 1) do not conflict with the impls that are already out there; 2) automatically cover any other crate that comes up with a clever way to package a slice of bytes, without adding a dependency to that crate from bytes or vice versa.

As suggested in my previous comment, I now think the new traits should augment the existing fully specialized operator traits rather than soft-deprecating them. The impl resolution rule does not need to be that complex, either. I will update the RFC with this idea.

[RustyYato]

Most of this tedium could be resolved through disciplined use of macros.

[mzabaluev]

I'm doing this, and it's still tedious 😄

[mzabaluev]

The macros also don't help when there is another clever container crate whose types compare to the same basic types as yours. You'd have to add a dependency on the crate, just for the impls. The authors of that crate might want to do the same for your crate, and now you have to mutually agree over what depends on what and under which feature flags.

The generic impl does it automagically and with no extra dependencies, as long as there is a fitting Borrow.

[RustyYato]

Why not just impl PartialEq and such for just the base varaints? Then force people to convert the owned versions to do the comparison? Is that too much of an ergonomic hit?

[mzabaluev]

Yes, using .as_str() and .as_bytes() everywhere for a workalike type with a different ownership model is incredibly annoying and inelegant. Especially considering that we have other generic APIs using Borrow where all lender types for the same target work interchangeably.

[RustyYato]

More than a few are unhappy with this precedent, and would like to see it changed.

[mzabaluev]

I see no really good alternatives that could have been chosen with the non-specializable Add for Rust 1.0. There are probably other considerations for some owned types without open-ended Borrow/Deref kinship. What do linear algebra people do?