[swift-evolution] [Pitch] Remove bit shift traps
swift-evolution at haravikk.me
Fri Mar 18 10:31:45 CDT 2016
> On 18 Mar 2016, at 12:10, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
> Le 18 mars 2016 à 07:03, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 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 >>).
> 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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution