[swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Joe Groff]

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Hello Swift Community,

The review of SE-0077: "Improved operator declarations" ran from May 17...23. On June 22, 2016, the core team decided to return the first version of this proposal for revision. The core design proposed is a clear win over the Swift 2 design, but the core team feels that revisions are necessary for usability and consistency with the rest of the language:

- The proposed associativity(left) and precedence(<) syntax for precedence group attributes doesn’t have a precedent elsewhere in Swift. Furthermore, it isn’t clear which relationship < and > correspond to in the precedence syntax. The core team feels that it’s more in the character of Swift to use colon-separated “key-value” syntax, with associativity, strongerThan, and weakerThan keyword labels:

precedencegroup Foo {
  associativity: left
  strongerThan: Bar
  weakerThan: Bas
}

-If “stronger” and “weaker” relationships are both allowed, that would enable different code to express precedence relationships in different, potentially confusing ways. To promote consistency and clarity, the core team recommends the following restriction: Relationships between precedence groups defined within the same module must be expressed exclusively in terms of strongerThan. weakerThan can only be used to extend the precedence graph relative to another module’s groups, subject to the transitivity constraints already described in the proposal. This enforces a consistent style internally within modules defining operators.

- The proposal states that precedence groups live in a separate namespace from other declarations; however, this is unprecedented in Swift, and leads to significant implementation challenges. The core team recommends that precedence groups exist in the same namespace as all Swift declarations. It would be an error to reference a precedence group in value contexts.

- Placing precedence groups in the standard namespace makes the question of naming conventions for precedencegroup declarations important. The core team feels that this is an important issue for the proposal to address. As a starting point, we recommend CamelCase with a -Precedence suffix, e.g. AdditivePrecedence. This is unfortunately redundant in the context of a precedencegroup declaration; however, precedencegroups should be rare in practice, and it adds clarity at the point of use in operator declarations in addition to avoiding naming collisions. The standard library team also requests time to review the proposed names of the standard precedence groups

- This proposal quietly drops the assignment modifier that exists on operators today. This modifier had one important function–an operator marked assignment gets folded into an optional chain, allowing foo?.bar += 2 to work as foo?(.bar += 2) instead of failing to type-check as (foo?.bar) += 2. In practice, all Swift operators currently marked assignment are at the equivalent of the Assignment precedence level, so the core team recommends making this optional chaining interaction a special feature of the Assignment precedence group.

- This proposal also accidentally includes declarations of &&= and ||= operators, which do not exist in Swift today and should not be added as part of this proposal.

Thanks Anton Zhilin for the proposal, and thanks to everyone who participated in the review! I will be taking over from Chris as review manager for the next round of revision.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/e8ab58f2/attachment.html>