[swift-evolution] [Pitch] Remove bit shift traps

[Dany St-Amant]

> Le 18 mars 2016 à 07:03, Haravikk via swift-evolution <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.

Dany

> 
>> On 18 Mar 2016, at 05:34, Patrick Pijnappel via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Currently, bit shifting with an amount greater than or equal to the size of the type traps:
>> 
>> func foo(x: Int32) {
>>   let y = x << 32 // Runtime trap (for any << or >> with amount >= 32)
>> }
>> 
>> I propose to make this not trap, and just end up with 0 (or ~0 in case of right-shifting a negative number):
>> 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.
>> 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. Int.max << 1 doesn't trap)
>> It could lead to bugs where users expect this to work, e.g. the following crashes when the entire buffer is consumed: buffer = buffer << bitsConsumed
>> Bitshift are often used in performance-sensitive code, and with the current behavior any non-constant bit shift introduces a branch.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160318/30c5cc2d/attachment-0001.html>