>>> set.elementsEqual(set)
>>
>> I see why that would work (thanks to Set being a collection vs a sequence),
>> but it still feels like a hack. I definitely wouldn’t want to be
>> maintaining code with that in it. Especially when compared to something like:
>>
>> set.contains(where: {$0.isNaN})
>>
>> The purpose of protocols is to enable useful generic code. You cannot use
>> isNaN for code that works on generic Collection, or for that matter, even
>> code that works on Set where Element : Numeric.
>>
>> Much generic code (for example, generic sorting) easily blows up when
>> encountering NaN. If you want an algorithm that is robust enough to handle
>> (or at least reject) that scenario, then you will need to check for it. It
>> is not a “hack” but a very common and accepted way of determining the
>> presence of NaN.
>
> Just because a hack is commonly accepted or common doesn’t mean it isn’t a
> hack.
>
> It’s not a “hack.” NaN is required by IEEE fiat not to be equivalent to
> itself. Asking whether a value is reflexively equivalent to itself is
> guaranteed to be sufficient to detect the presence of NaN in all
> IEEE-compliant contexts, which is to say all past, present, and future
> versions of Swift.
- while `a.elementsEqual(a)` returning true precludes the presence of a nan,
returning false is not a guarantee there is a NaN—at least the way you have
insist this method should work. The isNaN version is correct in all cases.
- It's a great deal less readable and obvious than the `where { $0.isNaN }`
version, so while the term "hack" is arguably not correct (assuming you only
need to disprove a NaN and not prove one exists), it is certainly not the most
readable way.
- IEEE says Float.nan == Float.nan must be false; I'm pretty sure the IEEE spec
doesn't say anything about how Swift Sequences must implement `elementsEqual`.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
