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

[David Sweeris]

Yes, I think that’s better.

I’m not sure how I feel about the “ing” at the end of the labels, but conceptually your idea is clearly the way to go, IMHO.

- Dave Sweeris

> On May 2, 2016, at 6: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)`
> 
> 
> On Mon, May 2, 2016 at 6:26 PM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On May 2, 2016, at 5:58 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> On May 2, 2016, at 1:56 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/bedbc92a/attachment.html>