[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

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

> 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.
>
> I view the gain in clarity/readability as functionality.
>

It is not a gain but a loss in clarity, because it introduces two spellings
for the same thing where now there is one.

Using ‘+’ instead of ‘adding(to:)’ may not have extra functionality by your
> definition, but it sure makes long equations easier for me to parse.
>

Again, _instead of_ is not the problem, but _in addition to_ is. We have
one way to spell less-than-or-equal-to in the standard library, and it is
`<=`. That goes again to the "opinionated" part of Swift language design.

The trampolining design that was required for `FloatingPoint` (with methods
like `dividing(by:)`, etc.) was an unfortunate artifact of that protocol
being approved before static operators; those methods were once necessary
for functionality and today are a wart that should not be emulated.

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.
>
> Thanks,
> Jon
>
>
> On Apr 13, 2017, at 8:09 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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/b014a1d1/attachment.html>