I tend to agree. I’d like the inconsistency concerning operators and dispatch to be resolved by investigating making operators into members, not by forcing operators to be second-class citizens. (Obviously this deserves its own proposal and its own discussion.)
Jordan > On Apr 26, 2016, at 08: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] > <mailto:[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] <mailto:[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] <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
