<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 27, 2016 at 1:14 PM Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>&gt; 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&#39;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&#39;t object.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; In this case, the compiler would automatically generate the global<br>
&gt; trampoline operator:<br>
&gt;<br>
&gt; func += &lt;T: TheProtocol&gt;(lhs: inout T, rhs: T) { T.+=(&amp;x, y) }<br>
<br>
Whoops: I didn&#39;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&#39;s time to go further, I<br>
wouldn&#39;t necessarily be opposed, but at this point it&#39;s extremely late<br>
to do anything ambitious.<br></blockquote><div><br></div><div>That&#39;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&#39;s likely to always be the same delegation, but since they can be written manually in 1–2 lines of code, that&#39;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&#39;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&#39;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 &quot;regular members&quot;, do you mean that `a + b` would become something like `a.+(b)`? (Sorry, I&#39;m entering some discussions late here.) I personally don&#39;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&#39;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 &quot;static&quot; protocol method to be dispatched dynamically, it doesn&#39;t need to be a method for that reason either if you&#39;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">&gt; Users could still refer to `T.+=` directly to obtain a reference to the `(inout<br>
&gt; T, T) -&gt; Void` function, but would likely only need to do this in the context of<br>
&gt; generic algorithms, and then only in situations where the compiler needed more<br>
&gt; help inferring the argument types (if `+=` by itself didn&#39;t provide enough<br>
&gt; context).<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; – Steve<br>
&gt;     &gt;<br>
&gt;     &gt; _______________________________________________<br>
&gt;     &gt; swift-evolution mailing list<br>
&gt;     &gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt;     --<br>
&gt;     Dave<br>
&gt;<br>
&gt;     _______________________________________________<br>
&gt;     swift-evolution mailing list<br>
&gt;     <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
<br>
--<br>
Dave<br>
</blockquote></div></div>