On Tue, Apr 26, 2016 at 12:36 PM, Nicola Salmoria via swift-evolution < [email protected]> wrote:
> On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato <[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. >> > > Well, I'm not sure about that. A protocol describes what a type can do, so > it's debatable whether a global function is within this scope. > > Operators are magically special: you can declare them inside a protocol > and require them to be available for conformance, even if they don't belong > to the type. You can't do the same thing for normal global functions, yet > conceptually global functions and operators are the same thing. > On the contrary, to my mind that's an argument to find some way to express global functions as requirements for protocol conformance. > >> 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. >> > > The difference at the protocol declaration is between: > > protocol Equatable { > func ==(lhs: Self, rhs: Self) -> Bool > } > > and: > > protocol Equatable { > func isEqual(to other: Self) -> Bool > } > > func ==<T: Equatable>(lhs: T, rhs: T) -> Bool { > return lhs.isEqual(to: rhs) > } > > so the latter is a bit more verbose, but arguably clearer in intent, and > not different from how you would define any generic global function using a > protocol, or from how you can define protocol extensions with default > implementations that take advantage of the protocol's core methods. > > The difference for the conformance is between: > > extension Foo : Equatable { } > > func ==(lhs: Foo, rhs: Foo) -> Bool { > return <comparison> > } > > and: > > extension Bar : Equatable { > func isEqual(to: Bar) -> Bool { > return <comparison> > } > } > > the former way to define the conformance can be confusing to newbies. The > latter is straightforward and consistent with the usual way to adopt a > protocol. > > The == operator looks exactly the same at its use points, but the way how > it's implemented is different. > In the former case, it's many overloads of a global function, which can > stress the compiler's type inference and doesn't offer an obvious way to > disambiguate in case of ambiguities. > In the latter case, there is only one generic definition of ==, which > automatically applies to all types that conform to the protocol. > > Nicola > > >> 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
