[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