<div dir="ltr">Great! Totally forgot to check those, even though I already skimmed them before ;). Looks like a lot of great improvements in one go!</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 9:52 AM, Dave Abrahams via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Thu Mar 17 2016, Patrick Pijnappel &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; Currently, bit shifting with an amount greater than or equal to the size of<br>
&gt; the type traps:<br>
&gt;<br>
&gt; func foo(x: Int32) {<br>
&gt;   let y = x &lt;&lt; 32 // Runtime trap (for any &lt;&lt; or &gt;&gt; with amount &gt;= 32)<br>
&gt; }<br>
&gt;<br>
&gt; I propose to make this not trap, and just end up with 0 (or ~0 in case of<br>
&gt; right-shifting a negative number):<br>
&gt;<br>
</span>&gt;    - Unlike the traps for integer arithmetic and casts, it is obvious what<br>
<span class="">&gt;    a bitshift past the end does as fundamentally the behavior stays the same.<br>
</span>&gt;    - If the intention is to make it analogous with multiplication/division<br>
<span class="">&gt;    by 2**n, the checks don&#39;t really change anything. Right shift are still<br>
&gt;    identical to divisions by 2**n. Left shifts are like multiplication by 2**n<br>
&gt;    but with different overflow behavior, which is already the case with the<br>
&gt;    current rules (e.g. Int.max &lt;&lt; 1 doesn&#39;t trap)<br>
</span>&gt;    - It could lead to bugs where users expect this to work, e.g. the<br>
<span class="">&gt;    following crashes when the entire buffer is consumed: buffer = buffer &lt;&lt;<br>
&gt;    bitsConsumed<br>
</span>&gt;    - Bitshift are often used in performance-sensitive code, and with the<br>
<span class="">&gt;    current behavior any non-constant bit shift introduces a branch.<br>
<br>
</span>This is addressed in<br>
<a href="https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb</a><br>
which we intend to propose very soon.<br>
<br>
(negative shift amounts work too).<br>
<br>
<a href="https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L1628" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L1628</a><br>
<br>
For users who want to be sure they&#39;re not paying for any checks, there<br>
is a masking bitshift (&amp;&lt;&lt;, &amp;&gt;&gt;, &amp;&lt;&lt;=, &amp;&gt;&gt;=).<br>
<br>
--<br>
-Dave<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>