> Le 18 mars 2016 à 07:03, Haravikk via swift-evolution > <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
