Ambiguous implicits when requesting Eq when both Hash and Order are present

[denisrosset]

Now that the RC ship has sailed, I don't know if this should be addressed at all.

Due to the fact that PartialOrder and Hash both extend Eq, we will run into ambiguous implicits when writing:

def fun[A:Hash:Order](x: A, y: A): Boolean = {
  x === y
}

One solution is to cap the hierarchy by defining HashPartialOrder, HashOrder in libraries that depend on cats, at the loss of some interoperability. Another option is to have Hash only depend implicitly on Eq (I guess that's the solution used in the cats-mtl library, right?)

Pinging @ctongfei

[denisrosset]

Note: I ran into the same problems in Spire, and we tried to use self-types to hide the subtyping.

trait Hash[A] {
self: Eq[A] =>

}

but specialization ruins the party.

[ctongfei]

Ah this problem surfaced again.

I wonder what is your usage for fun? Normally you just need either Hash or Order (e.g. a set is either a TreeSet that uses an Order or a HashSet that uses a Hash).

[denisrosset]

Trying to come up with an example, maybe that's not a big deal after all.

I started to write a PR to explore what a Hash that does not extends Eq looks like, it ends up being suboptimal in other ways.

Let's not forget that Eq will probably not be declared coherent (see #1995), so this is a design decision that we will have to live with after 1.0.0 is out.

[LukaJCB]

One could always do Hash[A].eqv or Order[A].eqv if you actually need both, no?

[johnynek]

this is not dissimilar to PartialOrder and Order and Eq. I think our answer here is to just use Hash[A] and understand that Hash extends Eq

you could do ev: Hash[A] with Eq[A] which I guess will at least document more.