<div dir="ltr">On Wed, Jun 22, 2016 at 10:24 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md</a><br><br>Hello Swift Community,<br><br>The review of SE-0077: "Improved operator declarations" ran from May 17...23. On June 22, 2016, the core team decided to <b>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><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>- The proposed <font face="Menlo">associativity(left)</font> and <font face="Menlo">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">associativity</font>, <font face="Menlo">strongerThan</font>, and <font face="Menlo">weakerThan</font> keyword labels:</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><br></div><div><font face="Menlo">precedencegroup Foo {</font></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><font face="Menlo"> associativity: left</font></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><font face="Menlo"> strongerThan: Bar</font></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><font face="Menlo"> weakerThan: Bas</font></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><font face="Menlo">}</font></div></div></div></blockquote></blockquote><div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>-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">strongerThan</font>. <font face="Menlo">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></div></blockquote><div><br></div><div>This definitely looks cleaner, but the terminology "stronger" and "weaker" is pretty non-standard. Typically, precedence is said to be above or below (equivalently, over or under, higher or lower) or, alternatively, before or after. IMO, before and after are particularly apt terms for operators, because `*` having precedence before `+` means precisely that `*` is evaluated before `+`. It's kind of a mixed metaphor to associate precedence with being stronger and weaker, though I suppose in life as well the stronger get to go first in line if they want to... </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><br></div><div>- 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"><div><div><br></div><div>- 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">CamelCase</font> with a<font face="Menlo"> -Precedence</font> suffix, e.g. <font face="Menlo">AdditivePrecedence</font>. This is unfortunately redundant in the context of a <font face="Menlo">precedencegroup</font> declaration; however, <font face="Menlo">precedencegroup</font>s should be rare in practice, and it adds clarity at the point of use in <font face="Menlo">operator</font> declarations in addition to avoiding naming collisions.</div></div></blockquote></div></blockquote><div><br></div><div>Conceptually, precedence groups feel to me like enum cases in a squishy kind of way, only you're not defining them all in one place. I wonder if that intuition has wide enough appeal that lowerCamelCase might be more apt. If you stretch that analogy further, it might make sense for precedence groups to live in their own namespace as though they're cases for an unutterable enum.</div><div><br></div><div>```</div><div>// A way of thinking about namespacing precedence groups</div><div>// Not actually proposed to be a real thing</div><div>enum _PrecedenceGroup : Int {</div><div> case assignment = 90, ternary = 100, disjunctive = 110 /* etc. */</div><div>}</div><div>```</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>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"><div><div><br></div><div>- 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">foo?.bar += 2</font> to work as <font face="Menlo">foo?(.bar += 2)</font> instead of failing to type-check as <font face="Menlo">(foo?.bar) += 2</font>. In practice, all Swift operators currently marked <font face="Menlo">assignment</font> are at the equivalent of the <font face="Menlo">Assignment</font> precedence level, so the core team recommends making this optional chaining interaction a special feature of the <font face="Menlo">Assignment</font> precedence group.</div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><br></div><div>- This proposal also accidentally includes declarations of <font face="Menlo">&&=</font> and <font face="Menlo">||=</font> operators, which do not exist in Swift today and should not be added as part of this proposal.</div></div><div><br></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.<span class="HOEnZb"><font color="#888888"><div><br></div><div>-Joe</div></font></span></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>