Pardon me for jumping in, but is it too late I wonder to align things with the x86 instructions (that presumably inspired the “shr” operator name in the first place) ?
shr corresponding to >>> (logical bit shift)
sar corresponding to >> (arithmetic bit shift)
I appreciate this could be problematic as it would mean changing the current behaviour of shr, but as well as making a “matching pair” of operators (shr/sar) this would also make shr consistent with Delphi, for example.
Perhaps subject to a “compatability” setting in the compiler ?
Most programming languages use “shr” and “shl”. That said, we now support unsigned types in java which makes it work the same as on .net and nougat: shr depends on it’s signedness.
I think the potential for confusion/problems is when you specifically and explicitly wish to perform a logical shift, irrespective of the signedness of the type of value being shifted. Currently you have to use the compiler magic function, which feels a little clumsy compared to having an operator which would be exactly equivalent.
@deltics: The reason we have the system function at all was that we didn’t do unsigned types back then. You could say it’s deprecated in favor of unsigned types now.