<div dir="ltr"><div>I think we don'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) -> Self</span></div><div>```</div><div><br></div><div>Later:</div><div>```</div><div><div>postfix func ++ <T: SomeProtocol>(value: inout T) -> T {</div><div> return T.++(anyLabelYouWant: &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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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'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'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 <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br>
<br>
>> Additionally, I am generally +1 for the same reasons as Brent, but I<br>
>> have another caveat as well:<br>
>><br>
>> Defining prefix and postfix functions looks like this in the proposal:<br>
>><br>
>> static prefix func ++(value: inout Self) -> Self<br>
>> static postfix func ++(value: inout Self) -> Self<br>
>><br>
>> yet the proposal suggests calling them this way from these boilerplate<br>
>> methods:<br>
>><br>
>> prefix func ++ <T: SomeProtocol>(value: inout T) -> T {<br>
>> return T.++(prefix: &value)<br>
>> }<br>
>> postfix func ++ <T: SomeProtocol>(value: inout T) -> T {<br>
>> return T.++(postfix: &value)<br>
>> }<br>
><br>
> 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>
><br>
> func ++ <T: SomeProtocol>(prefix value: inout T) -> T {<br>
> return T.++(prefix: &value)<br>
> }<br>
><br>
> func ++ <T: SomeProtocol>(postfix value: inout T) -> T {<br>
> return T.++(postfix: &value)<br>
> }<br>
><br>
> Not would be written as:<br>
><br>
> func ! <B: BooleanType>(prefix value: B) -> Bool<br>
><br>
> While force-unwrap (if we had inout return values) would be written:<br>
><br>
> func ! <T>(postfix value: inout Optional<T>) -> inout T<br>
><br>
> `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>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><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>