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. Using ‘+’ instead of ‘adding(to:)’ may not have extra functionality by your definition, but it sure makes long equations easier for me to parse. 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] > <mailto:[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] >> <mailto:[email protected]>> wrote: >> >> On Thu, Apr 13, 2017 at 7:02 PM, Jonathan Hull via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]>> wrote: >>> >>> Online copy here: >>> >>> https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md >>> >>> <https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/NNNN-ComparisonReform.md> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
