[swift-evolution] [Draft][Proposal] Formalized Ordering

[Dave Abrahams]

on Fri Jul 22 2016, Matthew Johnson <swift-evolution at swift.org> wrote:

>> On Jul 22, 2016, at 9:48 AM, Karl via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 22 Jul 2016, at 03:32, Robert Widmann via swift-evolution
>>> <swift-evolution at swift.org
>
>>> <mailto:swift-evolution at swift.org>>
>>> wrote:
>>> 
>>> 
>>>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu
>>>> <xiaodi.wu at gmail.com
>>>> <mailto:xiaodi.wu at gmail.com>> wrote:
>>>> 
>>>> This is nice. Is `areSame()` being proposed because static `==` is
>>>> the status quo and you're trying to make the point that `==` in
>>>> the future need not guarantee the same semantics?
>>> 
>>> Yep!  Equivalence and equality are strictly very different things.
>>> 
>> 
>> As I understand it:
>> 
>> -> what we call “Equatable” today checks for equivalence. For value
>> types, equivalent is the same as equality (that’s why they are
>> values - two instances with the same data are indistinguishable).
>> -> For reference types, we have an instance-equality operator (===)
>> which checks for what I believe you mean by equality.
>
> Except that the standard floating point == is not an equivalence
> relation.  I’m not sure if the distinction introduced by this proposal
> is solely due to that or if there are other example use cases for
> making a distinction.

Floating point is just the most common/important example.  Different
domains (see posets for a random example
https://en.wikipedia.org/wiki/Partially_ordered_set) attach different
semantics to the standard mathematical comparison operators = ≠ < ≤ > ≥,
which in programming we traditionally write as ==, !=, <, <=, >, >=.

The points of this proposal are:

1. To decouple the meanings of these operators from the semantics
   required for generic algorithms to work (thus making it possible to
   use floating point in generic contexts).

2. Secondarily, to avoid dropping efficiency on the floor in compound
   comparisons.

>> 
>> Karl
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave