<div dir="ltr">Currently, bit shifting with an amount greater than or equal to the size of the type traps:<div><br></div><div><font face="monospace, monospace">func foo(x: Int32) {</font></div><div><font face="monospace, monospace">  let y = x &lt;&lt; 32 // Runtime trap (for any &lt;&lt; or &gt;&gt; with amount &gt;= 32)</font></div><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">I propose to make this not trap, and just end up with 0 (or ~0 in case of right-shifting a negative number):</font></div><div><ul><li><font face="arial, helvetica, sans-serif">Unlike the traps for integer arithmetic and casts, it is obvious what a bitshift past the end does as fundamentally the behavior stays the same.</font></li><li><font face="arial, helvetica, sans-serif">If the intention is to make it analogous with multiplication/division by 2**n, the checks don&#39;t really change anything. Right shift are still identical to divisions by 2**n. Left shifts are like multiplication by 2**n but with different overflow behavior, which is already the case with the current rules (e.g. </font><font face="monospace, monospace">Int.max &lt;&lt; 1</font><font face="arial, helvetica, sans-serif"> doesn&#39;t trap)</font></li><li><font face="arial, helvetica, sans-serif">It could lead to bugs where users expect this to work, e.g. the following crashes when the entire buffer is consumed: </font><font face="monospace, monospace">buffer = buffer &lt;&lt; bitsConsumed</font></li><li><font face="arial, helvetica, sans-serif">Bitshift are often used in performance-sensitive code, and with the current behavior any non-constant bit shift introduces a branch.</font></li></ul></div></div>