On Thu, Apr 13, 2017 at 11:00 PM, Jonathan Hull <[email protected]> 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 <[email protected]> wrote: > > On Thu, Apr 13, 2017 at 7:51 PM, Jonathan Hull <[email protected]> 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 <[email protected]> wrote: >> >> On Thu, Apr 13, 2017 at 7:02 PM, Jonathan Hull via swift-evolution < >> [email protected]> 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 < >>> [email protected]> wrote: >>> >>> Online copy here: >>> >>> https://github.com/airspeedswift/swift-evolution/blob/fa0071 >>> 38a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
