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