> On 18 Mar 2016, at 12:10, Dany St-Amant via swift-evolution
> <[email protected]> wrote:
>
>
> Le 18 mars 2016 à 07:03, Haravikk via swift-evolution
> <[email protected] <mailto:[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.
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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
