Re: [swift-evolution] Fix or remove Swift.min and Swift.max?

on Sun Jul 03 2016, Haravikk wrote: > There was a proposal a little while ago to change Comparable to have > an operator producing an enum (with ordered before, same and ordered > after cases) which provides strict ordering requirements (unlike the > current

Re: [swift-evolution] Fix or remove Swift.min and Swift.max?

There was a proposal a little while ago to change Comparable to have an operator producing an enum (with ordered before, same and ordered after cases) which provides strict ordering requirements (unlike the current comparable methods). I think this would serve as a better basis for replacing

Re: [swift-evolution] Fix or remove Swift.min and Swift.max?

+1, and bumping this topic. The background — which I'm sure Jens is aware of — is that IEEE-754 floating point numbers can't truly conform to Comparable. (The problematic case being that neither of `x < .nan`, `x == .nan`, or `x > .nan` can be `true`.) But given that the NaN-abolishing

[swift-evolution] Fix or remove Swift.min and Swift.max?

Hi all! Swift.min (and Swift.max) propagates nan or not depending on the order of its args: Swift.min(1.0, .nan) // 1.0 Swift.min(.nan, 1.0) // nan (!) Double.minimum(1.0, .nan) // 1.0 Double.minimum(.nan, 1.0) // 1.0 fmin(1.0, .nan) // 1.0 fmin(.nan, 1.0) // 1.0 The new static minimum and