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

Matthew Johnson matthew at anandabits.com
Wed May 18 14:44:54 CDT 2016

> 	* What is your evaluation of the proposal?

Mostly an enthusiastic +1.  This really cleans up one aspect of Swift that seemed un-Swifty.

Like others, I would prefer to see the trampoline automatically generated.  This is not just a boilerplate issue.  Consider the following from the proposal:

> This would only search the global namespace and find * <T: FooProtocol> as a match. The name lookup will not search for operators defined as type members, so the concrete implementation of Foo.* would be ignored; the trampoline operator would explicitly call it. The only way to reference a type member operator is to fully-qualify it with its type's name, and it may only be called using function-call syntax.

> This implies that a user could implement a more specific overload of global * for a concrete type (such as one that takes (Foo, Foo) as its arguments), which would bypass the trampoline operator. While we would not recommend that a user do this, it's not necessarily compelling to forbid it either.
The consequences of this allow for confusing ambiguity.  I can implement a type that conforms to two or more unrelated protocols that both have the same operator requirement.  This means there will be an ambiguity issue when top-level lookup sees multiple trampoline definitions for which my type is an equally good match.  

The only way to resolve the ambiguity is to manually define a top-level operator definition for my concrete type.  This has great potential to be confusing to users.  It also means that by retroactively conforming a type to a new protocol I can introduce ambiguity into code that used to work as expected, which would be even more confusing and frustrating.  The most unfortunate aspect of this is that we all know the trampolines *should* all have the same implementation that just calls through to the static / class operator method defined on the type itself.

This potential for ambiguity does not currently exist in Swift precisely because each type is required to define its own top-level operator implementation which is always going to be the best match during overload resolution.

If the compiler manages trampolines it can take responsibility for 1) ensuring that they all simply call through to the static implementation as expected and 2) provide trampolines for concrete types to resolve ambiguity when necessary.

Maybe these ambiguity issues are acceptable for a short time if we just can’t get automatic trampolines into Swift 3, but we should consider them carefully before moving ahead.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes.  The current mechanism feels out of place in Swift.

> 	* Does this proposal fit well with the feel and direction of Swift?

Very much so.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Most languages I know of the allow operator overloading do so in a similar way.  Some of them use an `adding` style naming convention for operator methods which I find very distasteful.  I’m really happy Swift is not going to take that path.  

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I followed the initial discussion and gave the specific details of the proposal a close look.

> More information about the Swift evolution process is available at
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> -Chris Lattner
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/1cc1ed12/attachment.html>

More information about the swift-evolution mailing list