> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
