<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md</a><br class=""><br class="">Hello Swift Community,<br class=""><br class="">The review of SE-0077: "Improved operator declarations" ran from May 17...23. On June 22, 2016, the core team decided to <b class="">return</b> 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:<br class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- The proposed <font face="Menlo" class="">associativity(left)</font> and <font face="Menlo" class="">precedence(<)</font> 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 <font face="Menlo" class="">associativity</font>, <font face="Menlo" class="">strongerThan</font>, and <font face="Menlo" class="">weakerThan</font> keyword labels:</div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><br class=""></div><div class=""><font face="Menlo" class="">precedencegroup Foo {</font></div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> associativity: left</font></div></div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> strongerThan: Bar</font></div></div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> weakerThan: Bas</font></div></div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><font face="Menlo" class="">}</font></div></div></div></blockquote></blockquote><div class=""><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">-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 <font face="Menlo" class="">strongerThan</font>. <font face="Menlo" class="">weakerThan</font> 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.</div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><br class=""></div><div class="">- 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.</div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><br class=""></div><div class="">- 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 <font face="Menlo" class="">CamelCase</font> with a<font face="Menlo" class=""> -Precedence</font> suffix, e.g. <font face="Menlo" class="">AdditivePrecedence</font>. This is unfortunately redundant in the context of a <font face="Menlo" class="">precedencegroup</font> declaration; however, <font face="Menlo" class="">precedencegroup</font>s should be rare in practice, and it adds clarity at the point of use in <font face="Menlo" class="">operator</font> declarations in addition to avoiding naming collisions. The standard library team also requests time to review the proposed names of the standard precedence groups</div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><br class=""></div><div class="">- 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 <font face="Menlo" class="">foo?.bar += 2</font> to work as <font face="Menlo" class="">foo?(.bar += 2)</font> instead of failing to type-check as <font face="Menlo" class="">(foo?.bar) += 2</font>. In practice, all Swift operators currently marked <font face="Menlo" class="">assignment</font> are at the equivalent of the <font face="Menlo" class="">Assignment</font> precedence level, so the core team recommends making this optional chaining interaction a special feature of the <font face="Menlo" class="">Assignment</font> precedence group.</div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><br class=""></div><div class="">- This proposal also accidentally includes declarations of <font face="Menlo" class="">&&=</font> and <font face="Menlo" class="">||=</font> operators, which do not exist in Swift today and should not be added as part of this proposal.</div></div><div class=""><br class=""></div></blockquote>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.<div class=""><br class=""></div><div class="">-Joe</div></body></html>