<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, May 3, 2016 at 10:44 AM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Mon May 02 2016, Chris Lattner <clattner-AT-apple.com> wrote:<br>
<br>
> On May 2, 2016, at 4:59 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> Hmm, a thought going in a slightly different direction: if these static<br>
> functions were called like any other function, there might not be a need for<br>
> having special rules for parameter labels, which can then be freed to denote<br>
> prefix and postfix operators. In other words, we could have:<br>
><br>
> * for infix operators, no labels, like so: `static func + (_ lhs: T, _ rhs:<br>
> T)`, used like this: `T.+(1, 2)`<br>
> * for prefix and postfix operators, a label, like so: `static func +<br>
> (prefixing value: T)`, used like this: `T.+(prefixing: 1)`<br>
><br>
> Using labels for this is pretty nice. "T.++(prefix: abc)” and “T.++(postfix:<br>
> abc)” seem like they could work!<br>
<br>
Doing that feels like it creates a very weird corner of the language<br>
rules. What "fix" are the static operators? Do they need to be<br>
declared as prefix and suffix as well as labeled? If not, do the label<br>
need to match up with a declared fixity of the operator?</blockquote><div><br></div><div>As I started writing this up, I ran into a couple issues:</div><div><br></div><div>If prefix/postfix are argument labels, do we still have to use the keyword before the function declaration as well? Seems we would have to, in order to do the correct argument list checking. This looks bad requiring it to be duplicated:</div><div><br></div><div> protocol Foo {</div><div> prefix func ++(prefix value: inout Self) -> Self</div><div> }</div><div><br></div><div>If we leave out the prefix/postfix keyword at the front, then now it's inconsistent with the way global operators are defined, and that's not good either.</div><div><br></div><div><span style="line-height:1.5">Fully-qualified operators don't have this problem, and as Chris pointed out earlier, they do compose nicely, so I'm starting to lean back in that direction again.</span><br></div><div><br></div></div></div>