<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 5/18/2016 10:21 AM, Tony Allevato
wrote:<br>
</div>
<blockquote
cite="mid:CAOw3ZeYO3G_4UTALzu1bnrwQH6whkB3euKGdGp3PHku-LsB+_w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Wed, May 18, 2016 at 12:10 AM Brent
Royal-Gordon via swift-evolution <<a
moz-do-not-send="true"
href="mailto:swift-evolution@swift.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">...<br>
<br>
What I'm suggesting is that, on unary operators, Swift
require either the keyword "prefix" or "postfix" on the
argument, and use that to differentiate between prefix and
postfix operators. No other keyword would be used or
permitted, and no keyword would be used or permitted on
infix operators' arguments.<br>
</blockquote>
<div><br>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div>I would be supportive of this. The syntax for static
prefix/postfix operators in that proposal was a matter of
some earlier debate (in e-mail threads, and a couple
comments in the pull request <<a moz-do-not-send="true"
href="https://github.com/apple/swift-evolution/pull/283">https://github.com/apple/swift-evolution/pull/283</a>>)
and was one of the parts of the proposal I thought felt
less natural.</div>
<div><br>
</div>
<div>I think we should definitely have a solution that
avoids duplication (so not having a `prefix` as a leading
keyword and as an argument label). Since prefix/postfix
operators are required to only have one argument, and
those arguments must already not have labels, introducing
prefix/postfix as labels instead of keywords to
distinguish them seems natural.</div>
<div><br>
</div>
<div>The other major benefit (which I mention in a PR
comment above) is that, if you have a prefix and postfix
operator with the same name, there is no way currently to
get function references to both of them (for passing to
other algorithms), because there are no labels used to
distinguish them. For example, if you use `++` as a
function reference (ignoring the fact that it's
deprecated), the REPL takes the last one that was defined.
(I didn't test what the compiler does, but presumably it's
arbitrary depending on the ordering of the data structures
used to store those operators.) Using argument labels
would solve this problem as well.</div>
</div>
</div>
</div>
</blockquote>
<br>
These are good arguments. After thinking on it more and reading
these then I do support this change over my proposed change,
especially given that there is already precedent to control the form
of operator function definitions in this way that I was unaware of.<br>
<br>
As far as binary operators go, would they need to have a mandatory _
in front of each argument to satisfy what you propose, Brent? That
is:<br>
<br>
<font face="Courier New, Courier, monospace">static func ==(_ lhs:
Self, _ rhs: Self) -> Bool</font><br>
<br>
...since by default lhs and rhs would be externally visible argument
labels, or is it better to not impose any such restriction and keep
things the way they are? The compiler could also mandate that those
names be lhs and rhs to keep consistency with prefix and postfix,
but that seems like it might not be palatable, and would probably
need to be bikeshedded a bunch at the very least.<br>
</body>
</html>