[swift-evolution] [Proposal] Improving operator requirements in protocols

[Tony Allevato]

On Tue, May 3, 2016 at 10:44 AM Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Mon May 02 2016, Chris Lattner <clattner-AT-apple.com> wrote:
>
> >     On May 2, 2016, at 4:59 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >
> >     Hmm, a thought going in a slightly different direction: if these
> static
> >     functions were called like any other function, there might not be a
> need for
> >     having special rules for parameter labels, which can then be freed
> to denote
> >     prefix and postfix operators. In other words, we could have:
> >
> >     * for infix operators, no labels, like so: `static func + (_ lhs: T,
> _ rhs:
> >     T)`, used like this: `T.+(1, 2)`
> >     * for prefix and postfix operators, a label, like so: `static func +
> >     (prefixing value: T)`, used like this: `T.+(prefixing: 1)`
> >
> > Using labels for this is pretty nice. "T.++(prefix: abc)” and
> “T.++(postfix:
> > abc)” seem like they could work!
>
> Doing that feels like it creates a very weird corner of the language
> rules.  What "fix" are the static operators?  Do they need to be
> declared as prefix and suffix as well as labeled?  If not, do the label
> need to match up with a declared fixity of the operator?


As I started writing this up, I ran into a couple issues:

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:

    protocol Foo {
        prefix func ++(prefix value: inout Self) -> Self
    }

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160503/f440d099/attachment.html>