<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 28 Aug 2016, at 14:04, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 28.08.2016 um 05:34 schrieb Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" 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="">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.<br class=""></div></blockquote><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=""><br class=""></div><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="">Isn't that true for almost everything?</div></div></div></blockquote></div><div class="">That reminds me on a feature that has been discussed and added before:</div><div class="">Making tuples conform to Comparable (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md</a>)</div><div class="">The implementation doesn't hurt me, but imho it's use is very limited as well.</div><div class=""><br class=""></div><div class="">As for comparing optionals, my preferred result would be an Optional<Bool>:</div><div class="">if (value < 5) ?? true {…</div><div class="">It makes no assumptions on the order, is clear and also concise.</div><div class=""><br class=""></div><div class="">Tino</div></div></div></blockquote><br class=""></div><div>This could be an interesting compromise, but I'd say it shouldn't use the same operator as it's meaning differs from the norm, but in that case you'd be looking at introducing <?, >? etc. which is a lot of new operators for the task (which the Swift team I think wants to avoid).</div><div><br class=""></div><div>As others have said, the proposal for a strict ordering operator ought to solve most of these issues, so it should probably be made a priority, as with it we can have strictly ordered, optional types, where the meaning of < (inferred from the strict ordering operator) is well defined, which ought to cover most types that will implement it.</div><div><br class=""></div><div>Otherwise I'd say your options are either to use nil coalescing (??) or re-implement the optional forms of the operators yourself where necessary (and deal with later once strict ordering is added). I think for most cases right now this should be sufficient; disruptive admittedly, but the best option for now IMO.</div></body></html>