<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>On Wed, Sep 7, 2016 at 10:02 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></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">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>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></span><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" target="_blank">https://graphics.stanford.edu/<wbr>~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" target="_blank">https://github.com/xwu/<wbr>FlowKit/blob/master/Source/<wbr>BitVector.swift</a><br></div><div><br></div><div>(Note that this specific example will soon be obsolete with new integer protocols.)</div></div></div></div></blockquote><div><br></div><div>Both of these actually seem to make pretty careful use of parentheses in expressions with mixed-precedence infix operators. In the former, I find only a small handful of cases where &amp; is mixed with +, *, or / — seemingly the minority.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><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></div></div></blockquote><div><br></div><div>I would think (hope) that any removals could easily yield automatic migrations by adding parens where they were previously implied. I would only be concerned with the possibility that such a migration would affect type-checking speed (an area that already needs improvement, and can be exacerbated by large expressions). </div></div></div></div>