<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 &lt;<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>&gt;
            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 &lt;<a moz-do-not-send="true"
                href="https://github.com/apple/swift-evolution/pull/283">https://github.com/apple/swift-evolution/pull/283</a>&gt;)
              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) -&gt; 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>