<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 10, 2017, at 12:22 AM, Jaden Geller via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Mar 9, 2017, at 11:20 PM, Nicholas Maccharoli via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family: 'comic sans ms', sans-serif; color: rgb(39, 78, 19);">Nevin,</div><div class="gmail_default" style="font-family: 'comic sans ms', sans-serif; color: rgb(39, 78, 19);"><br class=""></div><div class="gmail_default" style="font-family: 'comic sans ms', sans-serif; color: rgb(39, 78, 19);">Yeah I think this works well as an extension on `<span class="" style="font-family: monospace, monospace; font-size: 12.8px; color: rgb(34, 34, 34);">Comparable</span>`, &nbsp;`foo.clamped(to: 1...100)` seems pretty natural.</div><div class="gmail_default" style="font-family: 'comic sans ms', sans-serif; color: rgb(39, 78, 19);"><br class=""></div><div class="gmail_default" style="font-family: 'comic sans ms', sans-serif; color: rgb(39, 78, 19);">Why not go one step further and move the versions of min, max that take two arguments on over to `Comparable` as a protocol extension?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think that a symmetric operation like `min` or `max` ought to treat both arguments in a symmetric way. `3.max(with: 9)` not only reads badly, but privileges one argument over the other syntactically. I’d very much like to avoid this.</div></div></div></blockquote><div><br class=""></div>Agreed.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">I would be okay with removing top-level min and max if `Array` min and max could generate equivalent code given an array literal. This seems possible.</div></div></div></blockquote></div><br class=""><div class="">Yeah, it seems like it’d be&nbsp;<i class="">technically</i>&nbsp;possible, but not without either a lot of compiler magic (not only in somehow optimizing away the overhead of creating an Array, but `[1, 2].max()` returns an `Int?` instead of an `Int`) , or maybe a sufficiently sophisticated macro… The 1st is something we’re trying to avoid, and IIRC the 2nd is out-of-scope for Swift 4. Also, I’m wary of not having the normal “math.h” functions, simply because they’re so universal.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div><div class=""><br class=""></div></body></html>