<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 Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;">Looking good. A few comments inline:</div><br class="" 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;"><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 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><h3 id="L-code-comparable--code-" class="" style="color: rgb(17, 17, 17); margin: 21px 0px; font-size: 20px; line-height: 21px; font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif;"><code class="" style="line-height: 1;">Comparable</code></h3><p class="" style="color: rgb(17, 17, 17); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; word-wrap: break-word; margin: 1.3125em 0px; font-size: 1.1429em; line-height: 1.3125em;">Comparable will be changed to have a new ternary comparison method: <code class="" style="line-height: 1;">compare(_ other: Self) -> ComparisonResult</code>. <code class="" style="line-height: 1;">x.compare(y)</code> specifies where to place x relative to y. So if it yields <code class="" style="line-height: 1;">.orderedAscending</code>, then x comes before y. This will be considered the new “main” dispatch point of Comparable that implementors should provide.</p><p class="" style="color: rgb(17, 17, 17); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; word-wrap: break-word; margin: 1.3125em 0px; font-size: 1.1429em; line-height: 1.3125em;">Most code will continue to use <code class="" style="line-height: 1;"><</code> or <code class="" style="line-height: 1;">==</code>, as it will be optimal for their purposes. However code that needs to make a three-way branch on comparison can use the potentially more efficient <code class="" style="line-height: 1;">compare</code>. Note that <code class="" style="line-height: 1;">compare</code> is only expected to be more efficient in this specific case. If a two-way branch is all that’s being done, <code class="" style="line-height: 1;"><</code> will be more efficient in many cases (if only because it’s easier for the optimizer).</p><p class="" style="color: rgb(17, 17, 17); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; word-wrap: break-word; margin: 1.3125em 0px; font-size: 1.1429em; line-height: 1.3125em;">For backwards compatibility reasons, <code class="" style="line-height: 1;">compare</code> will have a default implementation defined in terms of <code class="" style="line-height: 1;"><</code>, but to enable only using <code class="" style="line-height: 1;">compare</code>, <code class="" style="line-height: 1;"><</code> and <code class="" style="line-height: 1;">==</code> will also have default implementations in terms of <code class="" style="line-height: 1;">compare</code>.</p><p class="" style="color: rgb(17, 17, 17); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; word-wrap: break-word; margin: 1.3125em 0px; font-size: 1.1429em; line-height: 1.3125em;">The compiler will verify that either <code class="" style="line-height: 1;">compare</code>, or <code class="" style="line-height: 1;"><</code> and <code class="" style="line-height: 1;">==</code>, are provided by every type that claims to conform to <code class="" style="line-height: 1;">Comparable</code>. This will be done in some unspecified way unavailable outside the standard library (it can be made available to in the future, but that’s an unnecessary distraction for this proposal).</p></div></div></div></div></blockquote><div class="">It feels weird to me to jump through all these hoops just for backwards compatibility. Seeing how even big projects might only have several Comparable conformances, wouldn’t it be worth removing the default implementation of compare and removing < from Comparable?</div></div></div></blockquote><br class=""></div><div>The core team cares a *lot* about backwards compatibility. The engineering effort involved in implementing this mutually-exclusive check is very small compared with the benefits of maintaining compatibility.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>