<div dir="ltr"><div>I've got another suggestion for the bike shedding, and a question.</div><div><br></div><div>The naming suggestion: why not simply 'precedes' and 'succeeds'? This avoids the conjoined words problem. Then you're just writing 'Multiplication { succeeds: Exponentiation, precedes: Addition }'.</div><div><br></div><div>The question: this syntax lets you declare a precedence group C and position it between two groups A and B in the precedence order. If no existing precedence relationship exists between A and B when this happens (I'm assuming neither is imported), then creating C between A and B implicitly creates that relationship.</div><div>Suppose wanted to define C's precedence so its operation preceded both A and B, or succeeded both A and B. Does that require an explicit declaration of which of A or B takes precedence? If not, would this be legal?:</div><div>'precedencegroup C { strongerThan: A, strongerThan: B }'<br></div><div><br></div><div> <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 23, 2016 at 3:52 PM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jun 23, 2016, at 8:18 AM, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div>1. I've revised the proposal to mostly meet the recommendations.<br></div></div></blockquote><div><br></div></span>Thanks continuing to push this forward! I’m really looking forward to this change and hope the revision is met with acceptance.</div><div><span class=""> <br><blockquote type="cite"><div><div><br><a href="https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-" target="_blank">https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-</a><br><a href="http://operator-precedence.md" target="_blank">operator-precedence.md</a><br><br>2. My reaction to the rationale:<br><br>precedencegroup Foo {<br> associativity: left<br> strongerThan: Bar<br> weakerThan: Bas<br>}<br><br>I agree with colons, but I would prefer above and below. Anyway, core <br>team will have at least one more chance to change their mind.<br></div></div></blockquote><div><br></div></span><div>This is the first time I have encountered the “stronger” and “weaker” terminology in this context. I am curious about the rationale for preferring those.</div><div><br></div><div>FWIW, I also prefer `above` and `below`. The terms I am most familiar with in discussing precedence are “higher” and “lower” (and is the vocabulary used here: <a href="https://en.wikipedia.org/wiki/Order_of_operations" target="_blank">https://en.wikipedia.org/wiki/Order_of_operations</a> for example). However, as with `strongerThan` and `weakerThan`, these would require `higherThan` and `lowerThan` in order to read well. `above` and `below` have a strong relationship to that common vocabulary while being more concise because they do not require including a word that only serves to make our code read like a phrase while offering no information.</div><span class=""><div><br></div><blockquote type="cite"><div><div><br>- The proposal states that precedence groups live in a separate <br>namespace from other declarations; however, this is unprecedented in <br>Swift, and leads to significant implementation challenges. The core team <br>recommends that precedence groups exist in the same namespace as all <br>Swift declarations.<br><br>How unfortunate. We will need to discuss naming convention and try not <br>to add too much visual clutter.<br><br>3. I also have a suggestion to discuss.<br><br>Under "Joining unrelated precedence groups" I see an algorithm that does <br>not match anything I've seen in network theory.<br><br>My suggestion is to make it a warning, not an error. It will reduce the <br>pressure on the language and compilers.<br><br>When we break down precedence hierarchy in a follow-up proposal, <br>developers will be able to use a library that will join precedence <br>groups and make their old code compile, although with warnings.<br><br>- Anton<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></blockquote></span></div><br></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>