<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px;white-space:pre-wrap">This suggestion has been pitched earlier and I&#39;ve expressed my opinion in those earlier threads, but I&#39;ll repeat myself here:</span><div><span style="font-size:12.8px;white-space:pre-wrap"><br></span></div><div><span style="font-size:12.8px;white-space:pre-wrap">I&#39;m hugely opposed to such changes to the precedence table. </span><span style="font-size:12.8px;white-space:pre-wrap">Those of us who work with bitwise operators on a regular basis have memorized their precedence in Swift (and other languages) and rely on such precedence to write readable, correct code without excessively nested parentheses.</span></div></div></blockquote><div><br></div><div>Could you point me towards some examples of such code? I don&#39;t write it very often, so I don&#39;t feel I can really evaluate this. (This seems analogous to the &quot;terms of art&quot; categorization from the API Design Guidelines threads.) Much of the code I would normally write using bitwise operators has been replaced with the SetAlgebra protocol methods provided on OptionSet types.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px;white-space:pre-wrap">Any change here would break existing, carefully constructed code, punishing those who *have* put in the effort to learn the precedence table. To any other user of Swift, it should come as no surprise that op</span><span style="font-size:12.8px;white-space:pre-wrap">erators *have* precedence and associativity, and it is not such a burden for a user either to memorize or to consult a table for these properties when they are unsure</span><span style="font-size:12.8px;white-space:pre-wrap">.</span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px;white-space:pre-wrap"><br></span></div><div><span style="font-size:12.8px;white-space:pre-wrap">There is no way whatsoever to use intuition to arrive at the exact precedence of `??`, or `as`,</span><span style="font-size:12.8px;white-space:pre-wrap"> or `&amp;&amp;`, or `||`, </span><span style="font-size:12.8px;white-space:pre-wrap">or `&amp;`, or `|`, or `^` or `&lt;&lt;`, or `&gt;&gt;`, and there will be no relative precedence that will prove intuitive to all. (That said, there is a rational basis for the relative precedence of `&amp;`, `|`, and `^` to each other.) </span><span style="font-size:12.8px;white-space:pre-wrap">If you believe this situation to be problematic, then you must conclude that we should remove relative precedence between any operators except perhaps the basic arithmetic operators  `+`, `-`, `*`, `/`.</span></div></div></blockquote><div><br></div><div>I hadn&#39;t really noticed until now that &amp;&amp; and || have a defined ordering, and can be mixed. These are operators I *do* use regularly, and mixing them still makes me uncomfortable / seems unclear. Clang provides a warning for this: -Wlogical-op-parentheses.</div><div><br></div><div>I have a hard time seeing why the bitwise and arithmetic operators should belong to the same set of precedence groups, such that &amp; and * are BOTH stronger than + and |.  Even if some people are more acquainted with the bitwise operators&#39; precedences, as you  say, why should &amp; be stronger than + ? Why should * be stronger than |  ?</div><div><br></div><div>How about this?</div><div><br></div><div><img src="cid:ii_157081aa7019da4f" alt="Inline image 3" width="409" height="477" style="margin-right: 0px;"><br></div><div><br></div><div>(Personally, I&#39;m comfortable with BitwiseShift being stronger than both the other bitwise and the arithmetic operators, because it&#39;s a close cousin of exponentiation.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px;white-space:pre-wrap">This line of reasoning would be a huge U-turn from the direction of Swift, which after all just revised the syntax with which custom operator precedence is defined. Such a feature would be totally out of place in a language where operators other than those for basic arithmetic are not supposed to have precedence relations with each other.</span></div><div><span style="font-size:12.8px;white-space:pre-wrap"><br></span></div><div><span style="font-size:12.8px;white-space:pre-wrap">(Of course, the relative precedence of arithmetic operators is in some ways arbitrary as well, though it is inherited from math that everyone knows. How did you learn it in the first place? You memorized it.)</span></div><div><div><div><br></div></div></div></div></blockquote><div><br></div><div>(from a later email)</div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The promise of Swift 3 was that going forward, only essential source-breaking changes would occur; here, nothing about operators has changed since version 1, yet all of a sudden we are considering how to fundamentally alter how they work. Existing code *will break*, and sometimes silently, if such changes are made.</blockquote><div class="gmail-HOEnZb" style="font-size:12.8px"><div class="gmail-adm"><div id="gmail-q_15704fbca4d46b3c_12" class="gmail-ajR gmail-h4"></div></div></div><div> </div><div>How could the breakage possibly be silent for a change like this?  I&#39;m not proposing to add any new precedence relationships, just to remove/separate existing ones.</div></div></div></div>