My biggest issue with Optional conforming to Comparable is that while a default implementation may sometimes be useful, it may not necessarily be the one you want. In that last example with lastName, if you wanted to change the policy for whether users without last name appear first or last, you&#39;d have to write more verbose code anyway. Generally, reading that code with just &quot;&lt;&quot; I would never remember what Swift would do with nil (do they go first or last?)<br><br>If you don&#39;t care that much, a simple one-liner without all those guards could also be:<br><br>users.sorted { ($0.lastName ?? &quot;&quot;) &lt; ($1.lastName ?? &quot;&quot;) }<br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 27, 2016 at 6:58 AM Charlie Monroe via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I have personally (ab)used this for the following:<div><br></div><div>class User {</div><div><span style="white-space:pre-wrap">        </span>var email: String</div><div><span style="white-space:pre-wrap">        </span>var firstName: String?</div><div><span style="white-space:pre-wrap">        </span>var lastName: String?</div><div>}</div><div><br></div><div>You have a list of users based on email, so last name is optional. In Swift 2.x, you can do:</div><div><br></div><div>users.sort({ $0.lastName &lt; $1.lastName })</div><div><br></div><div>Now, you need to do:</div><div><br></div><div>users.sorted({<br><span style="white-space:pre-wrap">        </span>guard let firstName = $0.0.lastName else {<br><span style="white-space:pre-wrap">                </span>return true<br><span style="white-space:pre-wrap">        </span>}<br><span style="white-space:pre-wrap">        </span><br><span style="white-space:pre-wrap">        </span>guard let secondName = $0.1.lastName else {<br><span style="white-space:pre-wrap">                </span>return false<br><span style="white-space:pre-wrap">        </span>}<br><span style="white-space:pre-wrap">        </span><br><span style="white-space:pre-wrap">        </span>return firstName &lt; secondName<br>})</div><div><br></div><div>Which aside from being a brain teaser how to properly maintain ordering when $0.0&#39;s lastName != nil &amp;&amp; $0.1&#39;s lastName == nil, adds additional few lines.</div><div><br></div><div>But I agree that it may come as confusing with Ints, etc. - with strings it kind of makes sense since nil is like an empty string which is placed in front of everything.</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On Aug 27, 2016, at 1:46 PM, Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><div><div><br>This change is going to have a HUGE impact for me. I use this sort of comparison _all the time_ and find it incredibly useful, and have had literally zero bugs caused by this. Surely I can&#39;t be the only one who uses this. I am not looking forward to copying &amp; pasting a reimplementation of the comparison functions into every single project I work on.</div></div></blockquote><br></div><div>Can you give some examples as to how this will have such a huge impact? Now that we have the ?? operator it seems that this is fairly easy to replace:</div><div><br></div><div><font face="Monaco"><span style="white-space:pre-wrap">        </span>value &lt; 5 // where value is of type Int?</font></div><div><br></div><div>With:</div><div><br></div><div><font face="Monaco"><span style="white-space:pre-wrap">        </span>(value ?? 0) &lt; 5</font></div><div><font face="Monaco"><br></font></div><div><br></div><div>The latter is completely clear what the behaviour of nil is.</div><div><br></div><div>Also, you can still re-add the operators where you need them, ideally with as limited a type as possible so you can make sure that it&#39;s behaviour is well defined.</div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">Javier Soto</div></div>