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

[Xiaodi Wu]

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)`


On Mon, May 2, 2016 at 6:26 PM, David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On May 2, 2016, at 5:58 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On May 2, 2016, at 1:56 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.++
>
>
> I’m not sure if this is exactly right, but it seems close.  I think that
> something like this is probably the best way to go, since it composes
> properly in arbitrary expressions.  It does have a surface level weirdness
> to it, but it also "makes sense” in terms of how operators work.
>
> Yeah… Maybe with parens?
>
> T.++(x)
> (x)T.++
>
> Or is that worse?
>
> - Dave Sweeris
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160502/9c12d015/attachment.html>