On Sun, Apr 23, 2017 at 1:46 AM, 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. > > 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. > This is a very good practical point. 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
