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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
