RFC: merge cmp::Eq and cmp::Equiv

[erickt]

Using @nikomatsakis's double dispatch overloading trick, we could merge cmp::Eq and cmp::Equiv. This would allow us to remove all the _equiv methods from HashMap.

You can find an implementation prototype here.

I mentioned this in IRC, and @pcwalton and @huonw mentioned that this could complicate type inference though, but I couldn't figure out a good case where merging the two would cause a problem.

[pnkfelix]

visting for triage, email from 2013-08-26.

So, I assume that #[deriving(Eq)] struct Foo<T> { ... } (for example) would, in this new world, cause the implicit introduction of an impl like:

impl<T:Eq<T>> Eq<Foo<T>> for Foo<T> {
  fn eq(&self, other: &Foo<T>) { ... <same as now> ... }
}

Is that right?

I'm not sure about the type inference implications. (@nikomatsakis, any comments?)

(I'm also not sure that the motivation of removing the _equiv methods from HashMap is a good one; but maybe one can always re-encode any previously behavior by wrapping one's keys in structs with their own non-derived implementation of Eq, so this objection may not be well motivated. Not sure yet.)

[pnkfelix]

I did spend a little while trying to see how hard it would be to hack this in. Its not something that can be done piecemeal, I don't think. At least my brief attempts to switch the lang_item over to Equiv or erickt's Eq2 did not go smoothly.

[nikomatsakis]

I think I prefer to keep Eq as homogeneous comparisons.

[pnkfelix]

so maybe we should close this? Or ask for input from the rest of the core team?

[sanxiyn]

Nominating.

[pnkfelix]

We're planning to keep Equiv (I thought briefly that we might drop Equiv, but it is important for servo use cases such as case-insensitive lookup in a table).

We don't think the change suggested here (see e.g. my comment above) has sufficient motivation. Use Eq for the simple monomorphic cases and Equiv for the cases when the types may differ.

Closing as wont-fix