<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch <span dir="ltr">&lt;<a href="mailto:jtbandes@gmail.com" target="_blank">jtbandes@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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">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></span><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></div></div></blockquote><div><br></div><div>Gladly. These (which cannot be copied verbatim into Swift, as C operator precedences are different):</div><div><a href="https://graphics.stanford.edu/~seander/bithacks.html">https://graphics.stanford.edu/~seander/bithacks.html</a><br></div><div><br></div><div>Lest you think I&#39;m giving you a C example because I don&#39;t actually use such things in Swift, here&#39;s me using some of these:</div><div><a href="https://github.com/xwu/FlowKit/blob/master/Source/BitVector.swift">https://github.com/xwu/FlowKit/blob/master/Source/BitVector.swift</a><br></div><div><br></div><div>(Note that this specific example will soon be obsolete with new integer protocols.)</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 class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><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></span><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></div></div></blockquote><div><br></div><div>Just like &lt;&lt; is a &quot;close cousin&quot; of exponentiation, &amp; is a multiplication-like operator and ^ and | are addition-like operators on Boolean rings. To quote from previous messages in the older thread (from Felix Cloutier and Steve Canon):</div><div><br></div><div><div style="min-height:100%"><div class="gmail-nH" style="width:1920px"><div class="gmail-nH"><div class="gmail-nH"><div class="gmail-no"><div class="gmail-nH gmail-nn" style="width:1718px"><div class="gmail-nH"><div class="gmail-nH"><div class="gmail- gmail-ar4 gmail-B gmail-aeI"><div class="gmail-AO"><div id="gmail-:4" class="gmail-Tm gmail-aeJ" style="height:978px"><div id="gmail-:2" class="gmail-aeF" style="min-height:552px"><div class="gmail-nH"><div class="gmail-nH"><div class="gmail-nH gmail-g"><table class="gmail-Bs gmail-nH gmail-iY" cellpadding="0" style="width:1688px"><tbody><tr><td class="gmail-Bu"><div class="gmail-nH gmail-if"><div class="gmail-nH gmail-aHU"><div class="gmail-nH gmail-hx"><div class="gmail-nH"><div class="gmail-h7 gmail-" tabindex="-1"><div class="gmail-Bk" style="width:1429px"><div class="gmail-G3 gmail-G2"><div id="gmail-:20z"><div class="gmail-adn gmail-ads"><div class="gmail-gs"><div id="gmail-:211" class="gmail-ii gmail-gt gmail-adP gmail-adO" style="font-size:12.8px"><div id="gmail-:210" class="gmail-a3s gmail-aXjCH gmail-m1564bcc31ef6ef7e"><div style="word-wrap:break-word"><span class="gmail-im"><blockquote type="cite" style="font-size:12.8px"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">On Aug 2, 2016, at 12:18 AM, Félix Cloutier via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>I disagree. The binary <span class="gmail-il">operators</span> have properties that are comparable to arithmetic <span class="gmail-il">operators</span>, and their <span class="gmail-il">precedence</span> is easy to define as such. &amp; has multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their precedences are set accordingly (&amp; is multiplicative, | and ^ are additive).<span class="gmail-im"><br style="font-size:12.8px"></span>&lt;extreme pedantry&gt;<br>`^` is actually the *addition* <span class="gmail-il">operator</span> on Boolean rings[1].  `x | y` corresponds to the Boolean ring operation `x + y + xy`, which is definitely “addition-like” but isn’t addition.<br>&lt;/extreme pedantry&gt;<br>Otherwise, spot on.<br>– Steve<br>[1] Of course, it’s *also* the subtraction <span class="gmail-il">operator</span>, because `x = -x` for all members `x` of a Boolean ring (<a href="https://en.wikipedia.org/wiki/Boolean_ring" target="_blank">https://en.wikipedia.org/<wbr>wiki/Boolean_ring</a>), but one usually calls it “addition&quot;.</blockquote></blockquote></span></div></div></div></div></div></div></div></div></div></div></div></div></div></td></tr></tbody></table></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></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 class="gmail_extra"><div class="gmail_quote"><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><span class="gmail-"><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></span><div>(from a later email)</div><span class="gmail-"><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 style="font-size:12.8px"><div><div></div></div></div><div> </div></span><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></blockquote><div><br></div><div>The proposals include both breaking precedence relations and changing them; changing them will essentially always cause silent changes in existing code. Removing relations won&#39;t; however, it will necessitate sometimes difficult migrations, as formulas are complicated.</div><div><br></div><div>I have, I think, a simple but effective argument in defense of the current scheme of operator precedences, but since it&#39;s midnight here, I&#39;ll let others chime in and return to the discussion later.</div></div><br></div></div>