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

[Kevin Lundberg]

All good points, I'll hold off on this for now then. Would addressing the bigger picture issues you bring up be something feasible for Swift 3?

— Kevin


> On Mar 7, 2016, at 9:08 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 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
>