<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="">Oh come on. You are exaggerating the issue here. As I said, there isn’t really any extra maintenance needed and people are already familiar with their meaning. It isn’t like they have to learn new archaic symbols. Even HTML defines a special code for them because their use is common. There is only one reasonable implementation, and they can’t have another meaning without causing confusion. They are pretty easy to type on most keyboards.<div class=""><br class=""></div><div class="">I view the gain in clarity/readability as functionality. Using ‘+’ instead of ‘adding(to:)’ may not have extra functionality by your definition, but it sure makes long equations easier for me to parse. This is something that should have been there since the beginning. I know it isn’t a high priority, but since we are re-writing the protocol anyway, we should take the 3 seconds it takes to add them and do it. I am happy to provide the implementations if needed.<br class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 13, 2017, at 8:09 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Thu, Apr 13, 2017 at 7:51 PM, Jonathan Hull <span dir="ltr" class=""><<a href="mailto:jhull@gbis.com" target="_blank" class="">jhull@gbis.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I think “vastly” is vastly overstating it, especially since they are not customization points… merely aliases.</div></blockquote><div class=""><br class=""></div><div class="">It increases the number of methods on Comparable from 5 to 8, and it increases the number of standard operators (which will already expand if one-sided ranges are approved), with no functionality gain whatsoever. It doubles the number of ways to write three operators. And it expands the standard operators past the ASCII range, which was a choice deliberately not taken during the debate about how to name SetAlgebra members. If this is not a vast expansion, I do not know what is.</div><div class=""><br class=""></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" class="">There is nothing else those operators could do without causing confusion. Swift favors clarity, and these operators are much more clear (which I count as a benefit). Also ‘<=‘ looks like an arrow, which I find very distracting in code, as my eye wants to follow it.<div class=""><div class=""><br class=""></div><div class="">I do use this myself in application code, but I can’t add it to my framework code without potentially clashing with others (or myself) who have added the same behavior for themselves. Even though the implementations are exactly the same, it becomes ambiguous which of the (identical) definitions should be used. Having it in the library would mean that everyone would just use that version (and there is only one reasonable implementation, so it wont limit anyone).</div></div></div></blockquote><div class=""><br class=""></div><div class="">If it were in high demand, a de-facto standard would have arisen by now vending these symbols as a standalone library. For now, nothing stops you from defining them for internal use in your library.</div><div class=""><br class=""></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" class=""><div class=""><div class="">I really don’t think there is danger of harm here as you seem to be implying. Anyone who sees ‘≤’ will know what it means, even if they aren’t familiar with Swift. If the implementations point to ‘<=‘, etc… then nothing will get out of sync. There really isn’t any extra maintenance needed.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon<div class=""><div class="h5"><br class=""><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 13, 2017, at 5:03 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_3591221823944201086Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Thu, Apr 13, 2017 at 7:02 PM, Jonathan Hull via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">This is a sugar request, but if we are rearranging these things anyway, can we *please* add the ‘≤’, ‘≥’, and ‘≠’ operators to comparable. I know they would do the same thing as ‘<=‘, ‘>=‘, and ‘!=‘, but they can’t really be used for anything else without being confusing (because they literally have that meaning in mathematics), and they make my code so much more readable.</div></blockquote><div class=""><br class=""></div><div class="">This is vastly increasing API surface area for every user of Swift for literally no functionality. Why isn't it sufficient that Swift allows you to do this for yourself without restriction?</div><div class=""> </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" class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon<span class=""><br class=""><div class=""><br class=""></div><div class=""> <br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 13, 2017, at 1:24 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_3591221823944201086m_-219275219863727398Apple-interchange-newline"><div class=""><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;float:none;display:inline!important" class="">Online copy here:</span><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" 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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md" target="_blank" class="">https://github.com/airspeedswi<wbr class="">ft/swift-evolution/blob/fa0071<wbr class="">38a54895e94d22e053122ca24ffa0b<wbr class="">2eeb/proposals/NNNN-Comparison<wbr class="">Reform.md</a></div></div></blockquote></div><br class=""></div></span></div></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div></div></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div></body></html>