[swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Thorsten Seitz]

> Am 18.05.2016 um 23:20 schrieb Matthew Johnson via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> On May 18, 2016, at 4:06 PM, Tony Allevato <allevato at google.com> wrote:
>> 
>>> On Wed, May 18, 2016 at 1:56 PM Matthew Johnson via swift-evolution <swift-evolution at swift.org> 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160525/6ac03097/attachment.html>