<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">+1, and bumping this topic.</div><div class=""><br class=""></div><div class="">The background — which I'm sure Jens is aware of — is that IEEE-754 floating point numbers can't truly conform to <font face="Menlo" class="">Comparable</font>. (The problematic case being that neither of `<font face="Menlo" class="">x < .nan</font>`, `<font face="Menlo" class="">x == .nan</font>`, or `<font face="Menlo" class="">x > .nan</font>` can be `<font face="Menlo" class=""><b class="">true</b></font>`.)</div><div class=""><br class=""></div><div class="">But given that the <i class="">NaN-abolishing</i> semantics of `<font face="Menlo" class="">fmin</font>` is quite useful, and since we also want that <font face="Menlo" class="">Double</font> and <font face="Menlo" class="">Float</font> remain conforming to <font face="Menlo" class="">Comparable</font> (albeit brokenly), could we consider fixing this issue by moving `<font face="Menlo" class="">min(_:_:)</font>` and `<font face="Menlo" class="">max</font><span style="font-family: Menlo;" class="">(_:_:)</span>` into <font face="Menlo" class="">Comparable</font>?</div><div class=""><br class=""></div><div class="">The Comparable protocol would become:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> <b class="">public protocol</b> Comparable : Equatable {</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> < (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> <= (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> >= (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> > (lhs: Self, rhs: Self) -> Bool</font></div><div class=""><font face="Menlo" color="#9929bd" class=""> <b class="">static func</b> minimum(lhs: Self, rhs: Self) -> Self</font></div><div class=""><font face="Menlo" color="#9929bd" class=""> <b class="">static func</b> maximum(lhs: Self, rhs: Self) -> Self</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><br class=""></div><div class="">with default implementations added for the new static functions, and custom implementations for <font face="Menlo" class="">FloatingPoint</font> types. The `<font face="Menlo" class="">Swift.min</font>` and `<font face="Menlo" class="">Swift.max</font>` functions would then forward their logic to `<font face="Menlo" class="">Comparable.minimum</font>` and `<font face="Menlo" class="">Comparable.maximum</font>`.</div><div class=""><br class=""></div><div class="">— Pyry</div><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Jun 2016, Jens Persson wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_signature" data-smartmail="gmail_signature">Hi all!</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature"><div class="gmail_signature" data-smartmail="gmail_signature">Swift.min (and Swift.max) propagates nan or not depending on the order of its args:</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">Swift.min(1.0, .nan) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature">Swift.min(.nan, 1.0) // nan (!)</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">Double.minimum(1.0, .nan) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature">Double.minimum(.nan, 1.0) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">fmin(1.0, .nan) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature">fmin(.nan, 1.0) // 1.0</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div></div><div class="gmail_signature" data-smartmail="gmail_signature">The new static minimum and maximum funcs on FloatingPoint in Swift 3 shows the expected behaviour (ie the same as fmin, fmax and IEEE-754), so what should happen with Swift.min and Swift.max?</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature">Fix, remove or perhaps something else?</div><div class="gmail_signature" data-smartmail="gmail_signature"><br class=""></div><div class="gmail_signature" data-smartmail="gmail_signature"><a href="https://bugs.swift.org/browse/SR-1011" class="">https://bugs.swift.org/browse/SR-1011</a><br class=""></div></div></div></blockquote></div><br class=""></body></html>