<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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" 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></blockquote><div><br class=""></div><div>It isn’t just backwards compatibility. As someone who has worked with both forms of comparable, I can say that just implementing ‘<‘ is much easier, especially when you are just chaining results of comparing components. In one case I can just use ‘||' and ‘&&’, the other may require pattern matching in a switch. (I usually still have to implement ‘==‘ anyway in both cases, so it isn’t a difference between the two).</div><br class=""><blockquote type="cite" class=""><blockquote type="cite" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><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=""><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;"><span style="font-size: 20px;" class="">Different Names For </span><code class="" style="font-size: 20px; line-height: 1;">compare</code><span style="font-size: 20px;" class=""> and </span><code class="" style="font-size: 20px; line-height: 1;">ComparisonResult</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;">A few different variants for <code class="" style="line-height: 1;">ComparisonResult</code> and its variants were considered:</p><ul class="" style="margin-top: 21px; margin-bottom: 21px; padding-left: 1.5em; color: rgb(17, 17, 17); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; font-size: 11.999999046325684px;"><li class="" style="font-size: 13.19999885559082px;">Dropping the <code class="" style="line-height: 1;">ordered</code> part of <code class="" style="line-height: 1;">ComparisonResult</code>’s cases e.g. <code class="" style="line-height: 1;">.ascending</code></li><li class="" style="font-size: 13.19999885559082px;">Naming of <code class="" style="line-height: 1;">ComparisonResult</code> as <code class="" style="line-height: 1;">SortOrder</code></li><li class="" style="font-size: 13.19999885559082px;"><code class="" style="line-height: 1;">enum Ordering { case less, equal, greater }</code> (<a href="https://doc.rust-lang.org/std/cmp/enum.Ordering.html" class="" style="color: rgb(13, 110, 161); text-decoration: none; transition: color 0.2s ease-in-out;">as used by Rust</a>)</li><li class="" style="font-size: 13.19999885559082px;">Case values of <code class="" style="line-height: 1;">inOrder</code>, <code class="" style="line-height: 1;">same</code>, <code class="" style="line-height: 1;">outOfOrder</code></li></ul><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 choice of case names is non-trivial because the enum shows up in different contexts where different names makes more sense. Effectively, one needs to keep in mind that the “default” sort order is ascending to map between the concept of “before” and “less”.</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 before/after naming to provide the most intuitive model for custom sorts – referring to <code class="" style="line-height: 1;">ascending</code> or <code class="" style="line-height: 1;">less</code> is confusing when trying to implement a descending ordering. Similarly the inOrder/outOfOrder naming was too indirect – it’s more natural to just say where to put the element. If the enum should focus on the sorting case, calling it <code class="" style="line-height: 1;">SortOrder</code> would help to emphasize this fact.</p></div></div></div></div></blockquote><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Can you give an example where ascending/descending/equal can be confusing?</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote><div><br class=""></div><div>Agreed. Ascending & Descending imply an ordering to me. I don’t see how the extra ‘ordered’ clarifies anything…</div><br class=""><blockquote type="cite" class=""><blockquote type="cite" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><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=""><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;">This proposal elects to leave the existing Foundation name in-place. The primary motivation for this is that use of the <code class="" style="line-height: 1;">compare</code> function will be relatively rare. It is expected that in most cases users will continue to make use of <code class="" style="line-height: 1;">==</code> or <code class="" style="line-height: 1;"><</code>, returning boolean values (the main exception to this will be in use of the parameterized <code class="" style="line-height: 1;">String</code> comparisons). As such, the source compatibility consequences of introducing naming changes to an existing type seems of insufficient benefit.</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 method <code class="" style="line-height: 1;">compare(_:)</code> does not fully comport with the API naming guidelines. However, it is firmly established with current usage in Objective-C APIs, will be fairly rarely seen/used (users will usually prefer <code class="" style="line-height: 1;"><</code>, <code class="" style="line-height: 1;">==</code> etc), and alternatives considered, for example <code class="" style="line-height: 1;">compared(to:)</code>, were not a significant improvement.</p></div></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Uses of the compare function might be rare, but I still think it should follow the API naming guidelines. I don’t think that Objective-C conventions are a strong enough argument to warrant breaking those guidelines, especially in the Standard Library.</div></blockquote><br class=""></div><div>Agreed.</div><div><br class=""></div><div>Thanks,</div><div>Jon</div><br class=""></body></html>