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

[Tony Allevato]

On Mon, May 2, 2016 at 1:56 PM Dave Abrahams <dabrahams at apple.com> wrote:

>
> on Mon May 02 2016, Tony Allevato <allevato-AT-google.com> wrote:
>
> > On Mon, May 2, 2016 at 1:20 PM Dave Abrahams via swift-evolution
> > <swift-evolution at swift.org> wrote:
> >
> >     How does one distinguish between calls to a static prefix operator
> and a
> >     static postfix operator with the same name?
> >
> > Ah, that's a tricky one that I don't have an immediate answer to, so I'm
> > definitely open to creative thoughts here.
>
> One possibility: just use “qualified operator” notation.
>
>     lhs T.+= rhs
>
>     T.++x
>     x T.++
>

Even though this seemed a little odd when you first suggested it in the
other thread, it's growing on me now that we have to deal with this
ambiguity.

Fortunately the only situation I foresee where a person would explicitly
use this notation would be in the trampoline operator, so even if it looks
a little odd, at least it's isolated.


> > The first stab I would take at is, what if we included the token
> "prefix" or
> > "suffix" before the operator name in the expression, like this?
> >
> > return T.prefix ++(&value)
> > return T.postfix ++(&value)
> >
> > But that could start to look like an invocation of "++" on a static
> property
> > "T.prefix". I haven't dug into the parser to determine if that would
> even be
> > feasible or not.
>
> These are not unreasonable either:
>
> return prefix T.++(&value)
> return postfix T.++(&value)
>

I could get behind this one as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160502/d031b3b2/attachment.html>