I like this suggestion a lot. Using labels has a nice elegance to it and makes the usage very clear. If we drop the -ing like Chris suggests, it also aligns nicely with the same keywords used to define them.
I'm not a parser expert, but this seems like it might be easier to parse than fully-qualified operators. It is visually, at least. On Mon, May 2, 2016 at 4:59 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> 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)` > > > 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
