<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.&nbsp;On June 22, 2016, the core team decided to&nbsp;<b class="">return</b>&nbsp;the first version of this proposal for revision. The core design proposed is a clear win over&nbsp;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&nbsp;<font face="Menlo" class="">associativity(left)</font>&nbsp;and&nbsp;<font face="Menlo" class="">precedence(&lt;)</font>&nbsp;syntax for precedence group attributes doesn’t&nbsp;have a precedent elsewhere in Swift. Furthermore, it isn’t clear which relationship&nbsp;&lt;&nbsp;and&nbsp;&gt;&nbsp;correspond to in the&nbsp;precedence&nbsp;syntax. The core team feels that it’s more in the character of Swift to use colon-separated “key-value” syntax, with&nbsp;<font face="Menlo" class="">associativity</font>,&nbsp;<font face="Menlo" class="">strongerThan</font>, and&nbsp;<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&nbsp;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="">&nbsp; associativity:&nbsp;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="">&nbsp; 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="">&nbsp; 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&nbsp;relationships in different, potentially confusing ways. To promote consistency and clarity, the core team&nbsp;recommends the following restriction: Relationships between precedence groups defined within the same module&nbsp;must be expressed&nbsp;exclusively&nbsp;in terms of&nbsp;<font face="Menlo" class="">strongerThan</font>.&nbsp;<font face="Menlo" class="">weakerThan</font>&nbsp;can only be used to extend the&nbsp;precedence graph relative to another module’s groups, subject to the transitivity constraints already described in&nbsp;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&nbsp;unprecedented in Swift, and leads to significant implementation challenges. The core team recommends that&nbsp;precedence groups exist in the same namespace as all Swift declarations. It would be an error to reference a&nbsp;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&nbsp;precedencegroup&nbsp;declarations important. The core team feels that this is an important issue for the proposal to&nbsp;address. As a starting point, we recommend&nbsp;<font face="Menlo" class="">CamelCase</font>&nbsp;with a<font face="Menlo" class="">&nbsp;-Precedence</font>&nbsp;suffix, e.g.&nbsp;<font face="Menlo" class="">AdditivePrecedence</font>. This is unfortunately redundant in the context of a&nbsp;<font face="Menlo" class="">precedencegroup</font>&nbsp;declaration;&nbsp;however,&nbsp;<font face="Menlo" class="">precedencegroup</font>s should be rare in practice, and it adds clarity at the point of use in&nbsp;<font face="Menlo" class="">operator</font>&nbsp;declarations in addition to avoiding naming collisions. The standard library team also requests time to review the&nbsp;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&nbsp;assignment&nbsp;modifier that exists on operators today. This modifier had one&nbsp;important function–an operator marked&nbsp;assignment&nbsp;gets folded into an optional chain, allowing&nbsp;<font face="Menlo" class="">foo?.bar +=&nbsp;2</font>&nbsp;to work as&nbsp;<font face="Menlo" class="">foo?(.bar += 2)</font>&nbsp;instead of failing to type-check as&nbsp;<font face="Menlo" class="">(foo?.bar) += 2</font>. In practice, all Swift operators currently marked&nbsp;<font face="Menlo" class="">assignment</font>&nbsp;are at the equivalent of the&nbsp;<font face="Menlo" class="">Assignment</font>&nbsp;precedence level, so the core team recommends making this optional&nbsp;chaining interaction a special feature of the&nbsp;<font face="Menlo" class="">Assignment</font>&nbsp;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&nbsp;<font face="Menlo" class="">&amp;&amp;=</font>&nbsp;and&nbsp;<font face="Menlo" class="">||=</font>&nbsp;operators, which do not exist in Swift today&nbsp;and should not be added as part of this proposal.</div></div><div class=""><br class=""></div></blockquote>Thanks&nbsp;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>