<div dir="ltr">On Thu, Apr 13, 2017 at 7:51 PM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></span> wrote:<br><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">I think “vastly” is vastly overstating it, especially since they are not customization points… merely aliases.</div></blockquote><div><br></div><div>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><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">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><div><br></div><div>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><br></div><div>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><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"><div><div>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><br></div><div>Thanks,</div><div>Jon<div><div class="h5"><br><div><div><br><div><blockquote type="cite"><div>On Apr 13, 2017, at 5:03 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_3591221823944201086Apple-interchange-newline"><div><div dir="ltr">On Thu, Apr 13, 2017 at 7:02 PM, Jonathan Hull via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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">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><br></div><div>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> </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"><div><br></div><div>Thanks,</div><div>Jon<span><br><div><br></div><div> <br><div><blockquote type="cite"><div>On Apr 13, 2017, at 1:24 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_3591221823944201086m_-219275219863727398Apple-interchange-newline"><div><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">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"><br></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"><a href="https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md" target="_blank">https://github.com/airspeedswi<wbr>ft/swift-evolution/blob/fa0071<wbr>38a54895e94d22e053122ca24ffa0b<wbr>2eeb/proposals/NNNN-Comparison<wbr>Reform.md</a></div></div></blockquote></div><br></div></span></div></div><br>______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></div><br></div></div></div></div></div></div></div></blockquote></div><br></div></div>