It&#39;s not that &lt;&lt; will overflow and / will not. Substitute * for / and the argument would be the same. The difference is that &lt;&lt; traps when you shift more than the total number of bits but does *not* trap when you shift numbers off as would arithmetic exponentiation; * traps on overflow. Thus, what &lt;&lt; is concerned about is the bits (as it should), but * is concerned about the max representable value.<br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 2, 2016 at 16:41 Anton Zhilin &lt;<a href="mailto:antonyzhilin@gmail.com">antonyzhilin@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Here is the proposal draft:</div><a href="https://github.com/Anton3/swift-evolution/blob/remove-precedence-bitwise-arithmetic.md/proposals/NNNN-remove-precedence-bitwise-arithmetic.md" target="_blank">https://github.com/Anton3/swift-evolution/blob/remove-precedence-bitwise-arithmetic.md/proposals/NNNN-remove-precedence-bitwise-arithmetic.md</a><br><div><br></div><div>Motivation will be the most difficult section here.</div></div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-08-02 23:30 GMT+03:00 Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">Let me give you theoretical basis for why I&#39;m +0.5 on branching off binary operators but not these other ones. FĂ©lix is absolutely right that `a &lt;&lt; b / c` mixes two things. It&#39;s not merely that they&#39;re in two &quot;different&quot; domains. It&#39;s that these two operators take the same values of the same type and operate on them in fundamentally disparate ways.<br><br>This is a bad way of phrasing it, I know--let me try to clarify: the operator `&lt;&lt;` operates on an integer as a fixed-length collection of bits; the operator `/` operates on an integer as a number, an element in the set of all integers. The practical consequence is that overflow behavior can be subtly different; the overflow behavior of &lt;&lt; is &#39;obvious&#39; if you&#39;re thinking about an integer as a fixed-length collection of bits but surprising if you think of it as an integer being multiplied by an exponent of two. Thus, it is best to separate operators that work on integers as a collection of bits from the other numeric operators.<br><br>In no other of your proposed branches do I find the same fundamental conflict.</div></blockquote></div></div><div class="gmail_extra"><br></div></div><div dir="ltr"><div class="gmail_extra">And that argumentation seems insufficient to me. Assuming that everyone knows precedence table, &#39;a &lt;&lt; b / c` should not be ambiguous. I&#39;d argue that it&#39;s easy to understand that &lt;&lt; operation will overflow here and / will not.</div><div class="gmail_extra">Instead, I suggest that these operations are so different that any precedence relationship between them is meaningless (another wording of explanation with domains).</div></div>
</blockquote></div>