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

[Joe Groff]

IMO, simply repainting the bikeshed here doesn't carry much value, and since operators are purely compile-time syntax sugar, I don't think this is a priority to change for Swift 3.0. I see a couple deeper problems with how we model operators that deserve consideration for a deeper redesign, should you (or anyone else) dare to take them on. Coming up with a good solution to these problems might increase the value add here. For one, modeling relative precedence using a global integer table is bad and opaque, and not every operator makes sense to compose with every other. I think it would make more sense for operators to declare their precedence explicitly relative to the other operators they're intended to compose with. This would make operator declarations more self-documenting, operators more modular, and would also naturally give us the ability to raise errors for nonsensical operator combinations (similar to how C and C++ compilers complain about commonly-misunderstood operator combinations). Second, we don't handle operator conflicts between modules very well at all, giving essentially impossible-to-resolve conflict errors.

-Joe

> On Mar 5, 2016, at 8:54 PM, Kevin Lundberg via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Ever since Swift 1.0 I've found the infix operator attribute syntax strange:
> 
> infix operator <> { associativity left precedence 100 }
> 
> The value of the attribute has no visual cue that ties it to the name of
> the attribute. One could arguably read left as its own attribute name
> rather than the value set to the associativity attribute, or could read
> the wrong pair as one attribute, like "left precedence".
> 
> In the spirit of Erica Sadun's recent proposal to make attribute syntax
> uniform by using : over =, I'd like to see operator declaration syntax
> follow a similar structure:
> 
> infix operator <> { associativity: left, precedence: 100 }
> 
> In my opinion, this simple change makes operator attributes much more
> readable. This also should help future proof readability in operator
> attributes if operators gain more of them in the future. A longer list
> of attributes with the current syntax would become much harder to read.
> 
> The only (minor) sticking point I've noticed is the assignment attribute
> in the standard library:
> https://github.com/apple/swift/blob/12b793c87f160a0f18bb8762e425174205c5d80a/stdlib/public/core/Policy.swift#L427.
> This attribute isn't documented in TSPL and it has no value associated
> with it. Since user-defined operators are not meant to be assignment
> operators, it may not matter much how these are represented, but
> ostensibly some user-defined attribute that has no value may come about
> in the future. We could make these attributes simply look like this:
> 
> infixoperator+={ associativity:right,precedence: 90,assignment }
> 
> or perhaps we could make it so that this attribute must now have a
> Boolean value that defaults to false if it isn't provided:
> 
> infixoperator+={ associativity:right,precedence: 90,assignment: true }
> 
> Any thoughts?
> 
> - Kevin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution