[swift-evolution] [pitch] Comparison Reform

[David Waite]

> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I don’t think that this proposal is acceptable as written.  I think it is really bad that abstracting a concrete algorithm would change its behavior so substantially.  I don’t care about SNaNs, but I do care about the difference between +0/-1 and secondarily that of NaN handling.  It seems really bad that generalizing something like:
> 
> func doThing(a : Double, b : Double) -> Bool {
>   ….
>   return a != b
> }
> 
> to:
> 
> func doThing<T : FloatingPoint> (a : T, b : T) -> Bool {
>   ….
>   return a != b
> }
> 
> would change behavior (e.g. when a is -0.0 and b is +0.0).   Likewise, "T : Equatable”.

Did I misunderstand the proposal? If T : FloatingPoint is not included in level 1 comparisons, then you cannot have classes of generic floating point algorithms.

I personally feel sets/dictionaries of FloatingPoint keys to be more brittle than other types merely on the basis of the FloatingPoint numbers being an approximation within the real space. Different ways to compute a number may have different rounding errors, which makes container lookup less useful.

In my opinion this is much more about making generic algorithms relying on equatable/hashable/comparable able to make safe assumptions.

-DW