Dangerous default implementation of `==` under `Strideable`

[xwu (Xiaodi Wu)]

@lhunath

Now, I have some serious questions:

1. Why has adopting : Comparable voided the synthesized == conformance to Hashable?
2. Why has it done so entirely silently?
3. How is Comparable changing my default == if I don't specify it explicitly in the exact same way that Hashable would synthesize it?
4. Why does Comparable's documentation not indicate/warn about this?
5. Why are we allowing such a dangerous situation to develop entirely hidden from developer involvement?

The behavior you're seeing doesn't have to do with conforming to Comparable.

Rather, it's Strideable that has a default implementation of == (and <), and the presence of any non-synthesized implementation (default or not) takes precedence over the synthesized one (or rather more accurately, disables synthesis). Strideable's default implementation of equivalence boils down to lhs.distance(to: rhs) == 0.

The presence of these defaults is documented in Strideable, and it's even put in a box marked "Important":

The Strideable protocol provides default implementations for the equal-to (==) and less-than (<) operators that depend on the Stride type’s implementations.

The issue has been discussed here before, and there's even a hokey workaround I've suggested in the past to get the default synthesized implementation back.