[swift-evolution] [pitch] Comparison Reform

Xiaodi Wu xiaodi.wu at gmail.com
Thu Apr 13 22:09:20 CDT 2017

On Thu, Apr 13, 2017 at 7:51 PM, Jonathan Hull <jhull at gbis.com> wrote:

> I think “vastly” is vastly overstating it, especially since they are not
> customization points… merely aliases.

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.

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.
> 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).

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.

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.
> Thanks,
> Jon
> On Apr 13, 2017, at 5:03 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Thu, Apr 13, 2017 at 7:02 PM, Jonathan Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>> 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.
> 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?
>> Thanks,
>> Jon
>> On Apr 13, 2017, at 1:24 PM, Ben Cohen via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> Online copy here:
>> https://github.com/airspeedswift/swift-evolution/blob/fa0071
>> 38a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/7229297a/attachment.html>

More information about the swift-evolution mailing list