> On Apr 22, 2017, at 11:46 PM, David Waite <[email protected]> > wrote: > >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution >> <[email protected]> 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.
Sorry about that, my mistake, I meant “T: Comparable" -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
