<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>Le 18 mars 2016 à 07:03, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Since the trap represents a possible mistake, I think it’s better to keep it. However, we could have &<< and &>> operators that return the suggested defaults? This would also be more explicit that there is extra behaviour on the operation (so it may be a tiny bit slower than << and >>).</div></div></blockquote><div><br></div><div>Behaviour-wise, this &operator would be quite different that the other ones, as it doesn't handle overflow of the result, but an invalid rhs. If the meaning of &operator is that flexible, I think it may be better to use &<< and &>> for the missing rotate operator. I cannot say that I have ever had a use for rotate in high level language, but it have been quite useful in assembly.</div><div><br></div><div>Dany</div><br><blockquote type="cite"><div><br class=""><div><blockquote type="cite" class=""><div class="">On 18 Mar 2016, at 05:34, Patrick Pijnappel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Currently, bit shifting with an amount greater than or equal to the size of the type traps:<div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">func foo(x: Int32) {</font></div><div class=""><font face="monospace, monospace" class=""> let y = x << 32 // Runtime trap (for any << or >> with amount >= 32)</font></div><div class=""><font face="monospace, monospace" class="">}</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="arial, helvetica, sans-serif" class="">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 class=""><ul class=""><li class=""><font face="arial, helvetica, sans-serif" class="">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 class=""><font face="arial, helvetica, sans-serif" class="">If the intention is to make it analogous with multiplication/division by 2**n, the checks don'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" class="">Int.max << 1</font><font face="arial, helvetica, sans-serif" class=""> doesn't trap)</font></li><li class=""><font face="arial, helvetica, sans-serif" class="">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" class="">buffer = buffer << bitsConsumed</font></li><li class=""><font face="arial, helvetica, sans-serif" class="">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>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>