<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 27, 2016 at 1:14 PM Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>The one possible alternative I thought of would be to support infix<br>
notation, e.g.<br>
<br>
x T.+= y<br>
<br>
It might come down to what's easier to parse.<br></blockquote><div><br></div><div>That personally looks a bit awkward to me, but if it turned out to be significantly easier from a parsing point of view, I wouldn't object.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> In this case, the compiler would automatically generate the global<br>
> trampoline operator:<br>
><br>
> func += <T: TheProtocol>(lhs: inout T, rhs: T) { T.+=(&x, y) }<br>
<br>
Whoops: I didn't realize you were talking about doing that<br>
automatically. IMO the minimal change that could possibly fit in Swift<br>
3 would be to allow static operator declarations and calls, and have the<br>
library declare the trampolines. If there's time to go further, I<br>
wouldn't necessarily be opposed, but at this point it's extremely late<br>
to do anything ambitious.<br></blockquote><div><br></div><div>That's a reasonable compromise. My thinking was that it would be helpful for the compiler to provide the trampoline implicitly for protocol operators because it's likely to always be the same delegation, but since they can be written manually in 1–2 lines of code, that's not a significant burden.</div><div><br></div><div>As you say, if making the operators themselves static is doable in the Swift 3 timeframe, a longer-term plan could auto-define the trampolines and the compiler could either (1) flag ones identical to the would-be-auto-generated ones with a warning that they're redundant, or (2) silently accept them. (If we autogenerate, then we also have an open question: what do we do if the user declares their own trampoline that differs from the expectation? Do we let them override?)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Keep in mind though that several people in the community have long held<br>
that operators should be regular members, which presumably would<br>
obsolete these static members. On the other hand, we don't have a<br>
design for that change, which I think would require defining a new set<br>
of lookup rules. This is probably an incremental step in the right<br>
direction.<br></blockquote><div><br></div><div>My "regular members", do you mean that `a + b` would become something like `a.+(b)`? (Sorry, I'm entering some discussions late here.) I personally don't have a *strong* opposition to that, but I feel like arbitrarily elevating the left-hand side to be a receiver instead of an argument doesn't buy you much either. To me, `a + b` is computing a result based on two values on equal footing, not calling a method on one and passing it the other. And since class methods permit the "static" protocol method to be dispatched dynamically, it doesn't need to be a method for that reason either if you're implementing operators on a class hierarchy.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Users could still refer to `T.+=` directly to obtain a reference to the `(inout<br>
> T, T) -> Void` function, but would likely only need to do this in the context of<br>
> generic algorithms, and then only in situations where the compiler needed more<br>
> help inferring the argument types (if `+=` by itself didn't provide enough<br>
> context).<br>
><br>
> ><br>
> ><br>
> > – Steve<br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> --<br>
> Dave<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
--<br>
Dave<br>
</blockquote></div></div>