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] <mailto:[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] <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
