[swift-evolution] Universal Equatability, Hashability, and Comparability
Matthew Johnson
matthew at anandabits.com
Wed Mar 9 14:17:59 CST 2016
Sent from my iPhone
> On Mar 9, 2016, at 12:51 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> 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? 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.
+1 to this. There are many advantages to this approach and I am surprised that no languages (that I know of) have done this.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/d17b0441/attachment.html>
More information about the swift-evolution
mailing list