<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""></div></div></blockquote><div><br class=""></div><div>Mostly an enthusiastic +1. This really cleans up one aspect of Swift that seemed un-Swifty.</div><div><br class=""></div><div>Like others, I would prefer to see the trampoline automatically generated. This is not just a boilerplate issue. Consider the following from the proposal:</div><div><br class=""></div></div><blockquote type="cite" class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">This would only search the global namespace and find </span><code style="color: rgb(51, 51, 51); box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">* <T: FooProtocol></code><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> </span><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">as a match. The name lookup will</span><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> </span><em style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255); box-sizing: border-box;" class="">not</em><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> </span><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">search for operators defined as type members, so the concrete implementation of</span><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> </span><code style="color: rgb(51, 51, 51); box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">Foo.*</code><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""> </span><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">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.</span><br class=""></blockquote><br class=""><blockquote type="cite" class=""><div><div><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">This implies that a user could implement a more specific overload of global <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">*</code> for a concrete type (such as one that takes <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">(Foo, Foo)</code> 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.</p></div></div></blockquote><div><div></div></div><div><div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes. The current mechanism feels out of place in Swift.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>Very much so.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></blockquote><div><br class=""></div><div>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. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div></div></blockquote><div><br class=""></div><div>I followed the initial discussion and gave the specific details of the proposal a close look.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">More information about the Swift evolution process is available at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a><br class=""><br class="">Thank you,<br class=""><br class="">-Chris Lattner<br class="">Review Manager<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>