<div dir="ltr"><div>I think we don&#39;t need to invoke special compiler behavior. Namely, since the trampoline is manually generated, do this:</div><div><br></div><div>Static:</div><div>```</div><div><span style="color:rgb(80,0,80);font-size:12.800000190734863px">static func ++(anyLabelYouWant value: inout Self) -&gt; Self</span></div><div>```</div><div><br></div><div>Later:</div><div>```</div><div><div>postfix func ++ &lt;T: SomeProtocol&gt;(value: inout T) -&gt; T {</div><div>  return T.++(anyLabelYouWant: &amp;value)</div><div>}</div></div><div>```</div><div><br></div>On Tue, May 17, 2016 at 10:57 PM, Kevin Lundberg via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I do like this to a point, but it ascribes special compiler behavior to specific argument labels which feels odd. If someone defined another operator function with a completely different argument label, would it just be ignored? If a developer makes a typo, that could be a subtle bug that may be confusing. Or should the compiler only allow those two argument labels for unary operator functions? That feels strange since it&#39;s not a restriction present anywhere else, and it starts to feel like the labels have a dual purpose that also falls into the realm of keywords.<br>
<br>
Either option doesn&#39;t quite sit right with me, even though the lack of duplication that this solution has does look better, admittedly.<br>
<br>
--<br>
Kevin Lundberg<br>
<div class=""><div class="h5"><br>
On May 18, 2016, at 12:57 AM, Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com">brent@architechies.com</a>&gt; wrote:<br>
<br>
&gt;&gt; Additionally, I am generally +1 for the same reasons as Brent, but I<br>
&gt;&gt; have another caveat as well:<br>
&gt;&gt;<br>
&gt;&gt; Defining prefix and postfix functions looks like this in the proposal:<br>
&gt;&gt;<br>
&gt;&gt; static prefix func ++(value: inout Self) -&gt; Self<br>
&gt;&gt; static postfix func ++(value: inout Self) -&gt; Self<br>
&gt;&gt;<br>
&gt;&gt; yet the proposal suggests calling them this way from these boilerplate<br>
&gt;&gt; methods:<br>
&gt;&gt;<br>
&gt;&gt; prefix func ++ &lt;T: SomeProtocol&gt;(value: inout T) -&gt; T {<br>
&gt;&gt; return T.++(prefix: &amp;value)<br>
&gt;&gt; }<br>
&gt;&gt; postfix func ++ &lt;T: SomeProtocol&gt;(value: inout T) -&gt; T {<br>
&gt;&gt;   return T.++(postfix: &amp;value)<br>
&gt;&gt; }<br>
&gt;<br>
&gt; I actually found this bizarre too, but forgot to mention it. My suggested solution runs in the other direction: We should require that *all* unary operator declarations and references use `prefix` or `postfix` as a parameter label. Thus, the trampoline operators themselves would be written as:<br>
&gt;<br>
&gt;    func ++ &lt;T: SomeProtocol&gt;(prefix value: inout T) -&gt; T {<br>
&gt;        return T.++(prefix: &amp;value)<br>
&gt;    }<br>
&gt;<br>
&gt;    func ++ &lt;T: SomeProtocol&gt;(postfix value: inout T) -&gt; T {<br>
&gt;        return T.++(postfix: &amp;value)<br>
&gt;    }<br>
&gt;<br>
&gt; Not would be written as:<br>
&gt;<br>
&gt;    func ! &lt;B: BooleanType&gt;(prefix value: B) -&gt; Bool<br>
&gt;<br>
&gt; While force-unwrap (if we had inout return values) would be written:<br>
&gt;<br>
&gt;    func ! &lt;T&gt;(postfix value: inout Optional&lt;T&gt;) -&gt; inout T<br>
&gt;<br>
&gt; `prefix` and `postfix` would be eliminated from the language as declaration modifiers, except when declaring custom operators (which is already the Land Of Ad-Hoc Syntax).<br>
&gt;<br>
&gt; --<br>
&gt; Brent Royal-Gordon<br>
&gt; Architechies<br>
&gt;<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</div></div></blockquote></div><br></div></div>