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@swift.org> wrote: > > On May 2, 2016, at 5:58 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On May 2, 2016, at 1:56 PM, Dave Abrahams via swift-evolution < > swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
