<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 18 Mar 2016, at 12:10, Dany St-Amant 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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">Le 18 mars 2016 à 07:03, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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></blockquote></div><br class=""><div class="">Hmm, perhaps, though in some respects overflowing is what the 0 or ~0 represent, as you have shifted a value so far that all of the bits have shifted off the end, just an addition overflows because bits are lost from the end, the difference is that an addition may leave other bit positions filled resulting in the potentially invalid result. Of course you could also argue that every shift is causing overflowing in that sense, so yeah, maybe it isn’t clear enough.</div><div class=""><br class=""></div><div class="">Anyway, it’s an alternative, some other operator could do the same, either way I think that the current trap should remain due to the possibility of catching mistakes; code that can intentionally shift by too many places should have to do-so explicitly by some means IMO, rather than the operators doing this for everything, as it may not be what a programmer wanted to happen as a result of zero could create subtle bugs.</div></body></html>