> Am 18.05.2016 um 23:20 schrieb Matthew Johnson via swift-evolution > <[email protected]>: > > >> On May 18, 2016, at 4:06 PM, Tony Allevato <[email protected]> wrote: >> >>> On Wed, May 18, 2016 at 1:56 PM Matthew Johnson via swift-evolution >>> <[email protected]> wrote: >>> >>> Personally, I find Rust’s approach a bit ugly. And Tony makes a very good >>> point in the proposal that using words requires us to learn the word >>> associated with each operator. >> >> Right—and in addition to the cognitive overload of knowing (and remembering) >> the word associated with each operator, it introduced bloat in those >> interfaces. End users of such an interface may question why there is a named >> method for that operator, and whether the named method and the operator >> function differently. >> >> Likewise, in many cases (such as arithmetic operations), it seems contrived >> to come up with names for an operator where that operator is already a term >> of art that can express the idea better than the words can. >> >> >>> I noted some concerns about this proposal not including automatic >>> trampolines. However, if we are not going to be able to make a breaking >>> change like this in the standard library after Swift 3 I do think it is >>> important to give this proposal significant consideration even without >>> them. Automatic trampolines can be added later but we may not have the >>> opportunity to fix the standard library protocols later. >> >> I wish I had been able to keep automatic trampolines in—I thought it was the >> "killer feature" that brings the whole proposal together. (Hey core team, >> you can still change your mind! :) >> >> That being said, I feel that the named-method approach is a huge step in the >> wrong direction and this proposal is strong enough without them to improve >> other existing ones, such as FloatingPoint, and would go a long way toward >> cleaning up the language in other extremely common cases (like anything that >> conforms to Equatable). > > Tony (and core team), do you have any thoughts on the specific concerns I > brought up? > > Imagine this: > > protocol P { > static func ++++(lhs: Self, rhs: Self) -> Self > } > func ++++ <T: P>(lhs: T, rhs: T) -> T { > return T.++++(lhs, rhs) > } > > protocol Q { > static func ++++(lhs: Self, rhs: Self) -> Self > } > func ++++ <T: Q>(lhs: T, rhs: T) -> T { > return T.++++(lhs, rhs) > } > > struct S: P, Q { > static func ++++(lhs: Self, rhs: Self) -> Self { > // ... > } > } > > let s1 = S() > let s2 = S() > let s3 = s1 ++++ s2 // compiler error, both trampolines are an equally good > match, resulting in ambiguity > > // we have to add the following to resolve the ambiguity: > > func ++++(lhs: S, rhs: S) -> S { > return S.++++(lhs, rhs) > } > > You could argue that this is a contrived example and is unlikely to happen in > real code. My point is partly that it’s a regression from current state and > partly that it is very likely to be confusing if people run into it.
Actually I don't think this is a regression, it points to a deeper problem which already exists without the proposal and which is actually improved for the case you mentioned! When S conforms to P and Q which define different operators (semantically different) which share the same name, this is a name clash which should be resolved properly. Currently Swift is missing the means for that in general cases like methods with the same name. I wrote how Eiffel does this in a different thread quite some time ago. In your specific example this problem *can* actually be resolved which is a good thing! -Thorsten
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
