[swift-evolution] [pitch] Comparison Reform
xiaodi.wu at gmail.com
Thu Apr 13 23:20:36 CDT 2017
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.
> 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
>> 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
>> 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?
>>> On Apr 13, 2017, at 1:24 PM, Ben Cohen via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> Online copy here:
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution