[swift-evolution] Universal Equatability, Hashability, and Comparability

[Dave Abrahams]

on Wed Mar 09 2016, Joe Groff <jgroff-AT-apple.com> wrote:

>> On Mar 9, 2016, at 11:41 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>>> or a desired one. 
>> 
>> That's true.  But what's important is that it's consistent with == and
>
>> allows lookup in a sorted container.  The core ordering operation should
>> not be spelled "<" though; we should use "<=>" for that so that types
>> can keep their domain-specific "<" if necessary.  Too bad the same trick
>> doesn't work for "==" :-).
>> 
>>> Many people have complained that 'nil < .Some(1)' works for optionals,
>>> for instance, ordering 'nil' below Some values. We could use pointer
>>> identity to order class instances and types, but this wouldn't be a
>>> stable ordering across process runs. 
>> 
>> Oh, that's what you mean by "stable."  So what?
>
> What if we separated "ordering for a collection" from the < == >
> family altogether? 

Yes, that's what I was suggesting we do with <=>.  Heh, that works for
== too, I hadn't realized!

> Even Floats can be given a true equivalence relationship and assigned
> a stable total ordering for the purposes of container identity. I
> think it's reasonable for types to be able to provide an abstract
> ordering without making '<' and friends casually work. Programmers may
> have had "don't rely on hash order" drilled into their heads over the
> decades, and "don't rely on container order" might be a reasonable
> abstraction step from that, but "don't rely on < behavior" strikes me
> as unintuitive and going against the intuition users build up from
> common concrete manifestations of '<', such as numeric types.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4367.html
or
https://www.youtube.com/watch?v=fi0CQ7laiXE

might be interesting background.

-- 
-Dave