[swift-evolution] Proposal: change infix operator attributes syntax to be more consistent with the rest of the language

[Kevin Lundberg]

Personally I like the current way of declaring an operator's expected
"fixity" as it reads much more naturally:

infix operator += // reads "an infix operator named +="

when compared to

operator += (infix)
// or
operator += (fixity: infix) // reads as "an operator named += which has
a fixity of infix"

Additionally, (pre|post|in)fix-ness of an operator has a much greater
impact on how the operator is used when compared to
associativity/precedence, and if that was designated as a behavioral
modification parameter like associativity/precedence, then it might lead
one to think that they could just alter the fixity and leave the other
attributes alone even though those attributes are only valid for one of
those fixity types:

operator +=(fixity: prefix, associativity: right, precedence: 90,
assignment: true) // compiler error!

I don't like having the value of one parameter in a list control whether
other parameters are even allowed to be present, since that as far as
I'm aware isn't the case in any other aspect of Swift.

On 3/6/2016 12:51 AM, T.J. Usiyan via swift-evolution wrote:
> I'm not completely sold on the proposed change but, if we were to do
> something like this, I suggest we include `fixity` as a parameter and
> come up with something for `assignment` (`true` in my example is
> admittedly suboptimal ). Those `operator -(prefix) seems strange to me.
>
> ```
> operator +=(fixity: infix, associativity: right, precedence: 90,
> assignment: true) 
> operator -(fixity: prefix)
> operator !(fixity: postfix)
> ```
>
> On Sun, Mar 6, 2016 at 12:35 AM, Erica Sadun via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>     I like this approach too BUT my only concern is how long it takes
>     to get to the actual name. 
>     I know I probably hate this already (give me time to sleep on it)
>     and I'm not wedded to the 
>     approach, but I'd like to see the operator move left for
>     readability so that it's more like a 
>     func declaration:
>
>     operator +=(infix, associativity: right, precedence: 90, assignment) 
>     operator -(prefix)
>     operator !(postfix)
>
>     -- E
>
>>     On Mar 5, 2016, at 10:24 PM, Brent Royal-Gordon via
>>     swift-evolution <swift-evolution at swift.org
>>     <mailto:swift-evolution at swift.org>> wrote:
>>
>>>     infix operator += { associativity: right, precedence: 90,
>>>     assignment: true }
>>
>>     I'm a little uncomfortable putting what looks for all the world
>>     like a parameter list into curly brackets; it just doesn't feel
>>     in step with other declarations. (To be fair, I wasn't
>>     comfortable with the old way, either.)
>>
>>     Here's what I suggest. Usually, a bunch of parameters modifying a
>>     declaration would go in a parenthesized list after the particular
>>     keyword they modified, and in this case, `associativity` and
>>     `precedence` (and probably `assignment` too, though I don't know
>>     for sure since it's not documented) are only valid on an infix
>>     operator. That would suggest:
>>
>>     infix(associativity: right, precedence: 90, assignment) operator +=
>>     prefix operator -
>>     postfix operator !
>>
>>     -- 
>>     Brent Royal-Gordon
>>     Architechies
>>
>>     _______________________________________________
>>     swift-evolution mailing list
>>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> 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/20160306/0b87ffec/attachment.html>