Rewrite Comparator impls to get rid of the need for old_impl_check

[reem]

No description provided.

[apasel422]

I've been thinking about how to approach this, but it seems like the new rules will make comparators a lot more limited.

[Gankra]

@apasel422 Can you elaborate on the problems so I can pester core devs with it?

[apasel422]

@gankro Sure, let me organize my thoughts.

[apasel422]

@gankro I may be wrong, actually. I thought there was an issue relating to "early" vs. "late" binding of the types that a comparator can compare, but maybe not. Let me submit a PR with my proposed changes to see how it turns out.

[Gankra]

I'm currently trying to port it to associated types as well (need to learn this crap at some point)

[Gankra]

(getting walled on TreeMap's Compare<K> + Compare<Q, K> bounds @_@)

[apasel422]

I actually don't think associated types will work in general -- in particular, I think Borrow will be impossible to write.

[Gankra]

How did a type ever satisfy these bounds anyway?

[apasel422]

Do you mean Compare<K> + Compare<Q, K>? I don't know. It makes sense for it to be legal, but I don't know if rustc "officially" supports bounds like that yet.

In any case, see #76 for a fix.

[reem]

I remember there being problems with doing something like Get<A> + Get<B>, but that was a while ago so it might have been fixed/changed.