[swift-evolution] [pitch] Comparison Reform
Chris Lattner
clattner at nondot.org
Sun Apr 23 09:40:14 CDT 2017
> On Apr 22, 2017, at 11:46 PM, David Waite <david at alkaline-solutions.com> wrote:
>
>> 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.
Sorry about that, my mistake, I meant “T: Comparable"
-Chris
More information about the swift-evolution
mailing list