Dave Abrahams wrote: >> Given all this, I propose a simpler model that makes `a <=> b` follow >> the expected behaviour of < and ==, with the tradeoff that `a <=> >> .nan` and `.nan <=> b` will abort with a precondition failure: > > This effectively makes it a precondition violation to default-sort > a sequence of floats that contains a NaN
Correct. I'm still pondering if that could be alleviated in this model with minor modifications. Note however, that the proposed IEEE 754 total order would put negative NaNs at front and positive NaNs at the end. I can't say that's too useful either. > or even to ask whether > someSequence.contains(.nan). IMO that's not really acceptable. Not correct. Algorithms like contains(_:) or firstIndex(of:) would use the == operator which is part of the protocol and thus wouldn't call <=> on FloatingPoint types which override the default implementation. — Pyry _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
