+1 from me as well to Tony's write-up. -Thorsten
> Am 26.04.2016 um 17:54 schrieb Xiaodi Wu via swift-evolution > <[email protected]>: > > +1 to Tony's write-up. > >> On Tue, Apr 26, 2016 at 10:47 Tony Allevato via swift-evolution >> <[email protected]> wrote: >> That seems like a purely syntactic concern that could potentially be >> addressed in other ways, though. I'm not sure the choice of "duplicate all >> operators using verbosely-named methods" is the best one for the reasons I >> mentioned above, and the question of "how do we cleanly unify operators with >> other protocol requirements?" seems out-of-scope and orthogonal to this >> proposal. >> >> Given that we already have existing cases in the language where operators >> are declared within protocols (`Equatable` being the first one that comes to >> mind), I would recommend that this proposal follow that pattern for >> consistency and then the community continue a separate discussion about >> operators in protocols, which may or may not lead to changes across the >> entire language and standard library. The protocol operators discussion >> feels like a much larger topic that deserves to be discussed in its own >> right without bogging down the rest of this proposal. >> >> >>> On Tue, Apr 26, 2016 at 8:18 AM David Sweeris <[email protected]> wrote: >>> I’m with Nicola on this one. Operators are currently odd in that they have >>> to be declared globally. Everything else about protocol conformance is kept >>> within the conforming type. >>> >>> - Dave Sweeris >>> >>> >>>> On Apr 26, 2016, at 9:28 AM, Tony Allevato via swift-evolution >>>> <[email protected]> wrote: >>>> >>>>> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution >>>>> <[email protected]> wrote: >>>>> > > func isEqual(to other: Self) ->Bool >>>>> > > func isLess(than other: Self) ->Bool >>>>> > > func isLessThanOrEqual(to other: Self) ->Bool >>>>> > >>>>> > I'm still not sure why these are methods instead of operators. >>>>> >>>>> I think this is an *excellent* choice, and I hope it is the first step to >>>>> completely removing operators from protocols. >>>>> >>>>> IMHO throwing operators into protocols is inconsistent and confusing. >>>>> Having regular methods and a single generic version of the operator that >>>>> calls down on the type’s methods is clearer and guarantees that generic >>>>> code can avoid ambiguities by calling the methods directly, instead of >>>>> having to rely only on heavily overloaded global operators. >>>> >>>> I personally disagree on this point. To me, a protocol describes a set of >>>> requirements for a type to fulfill, which includes things other than >>>> methods. Just as a protocol can define initializers, properties, and >>>> associated types that a type must define in order to conform, it makes >>>> sense that a protocol would also define which operators a conforming type >>>> must support. >>>> >>>> Introducing a mapping between names and operators poses a few problems: >>>> >>>> – IMO, they are overly verbose and add noise to the definition. This makes >>>> the language look less clean (I'm getting visions of NSDecimalNumber). >>>> – They expose two ways to accomplish the same thing (writing >>>> `x.isEqual(to: y)` and `x == y`). >>>> – Do certain operators automatically get mapped to method names with >>>> appropriate signatures across all types, or does a conforming type still >>>> have to provide that mapping by implementing the operators separately? If >>>> it's the latter, that's extra work for the author of the type writing the >>>> protocol. If it's the former, does it make sense to automatically push >>>> these operators for all types? Should any type that has an `add` method >>>> automatically get `+` as a synonym as well? That may not be desirable. >>>> >>>> I'm very supportive of the floating-point protocol proposal in general, >>>> but I feel the arithmetic and comparison operations should be exposed by >>>> operators alone and not by methods, where there is a suitable operator >>>> that has the intended meaning. >>>> >>>> >>>>> >>>>> — >>>>> Nicola >>>>> >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
