[swift-evolution] [Draft] Rename Sequence.elementsEqual

[Kevin Nattinger]

>>> 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`.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171017/d2032bee/attachment.html>