Sent from my iPad
> On May 25, 2016, at 12:18 AM, Thorsten Seitz <[email protected]> wrote: > > > >> 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! I agree that you should have the ability to resolve the name clash of so desired. But it's also possible that your implementation is suitable for both protocols. For example, maybe they come from different modules that both define similar protocols and you conform to both to interoperate with them. > > -Thorsten
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
