Unsigned right shift semantics

[littledan]

Is there much meaning to unsigned right shift? With arbitrary-precision integers, there's not much meaning to 'signed' and 'unsigned', as we don't have any particular need to downcast to a signed or unsigned fixed width integer, as >>/>>> does on Numbers. For users who want to get at a 64-bit signed/unsigned integer's right shift functionality, that can be accessed by putting the left operand within the 64-bit signed or unsigned integer range.

I see a couple viable options for the semantics of >>>:

1. >> and >>> do the same thing
2. >>> throws a TypeError

My personal preference is for 2. There's no need to expose duplicate functionality under another name, and not exposing it would give us space to give it other semantics in the future if we find a need. BigInt is generally designed with generic code that works between Numbers and BigInts as an explicit non-goal, so there is no particular need to support >>> at all.

In earlier conversation with @msaboff, we discussed the possibility of some other semantics for >>>, but Waldemar Horwat pointed out that the bitwidth of a BigInt is not sufficiently defined to make that meaningful.

[kgryte]

I would prefer parity with current Int32 semantics. Meaning that >> and >>> behavior for arbitrary-precision integers match the behavior of Int32 integers.

Imposing different rules for different integer types (Int32 vs arbitrary-precision) will just lead to confusion. Code which operates on both flavors of integers will need to branch and apply different operations to get the same effective outcome. Furthermore, having to massage 64-bit integers by putting the left operand within a particular range will be a quirk and a source of frustration.

[littledan]

@kgryte Are you saying that we should do option 1 that I listed above?

[kgryte]

Would you be willing to provide examples showing how >> and >>> would do the same thing? Not clear to me why an operator which sign-propagates for Int32 and another operator which zero-fills for Int32 should have different behavior (in this case matching behavior) when applied to other integer sizes.

[littledan]

>>> casts its input to the range [0, 2³²) and >> casts its input to the range [-2³¹,2³¹) before doing its operation. For arbitrary-precision integers, it's not clear to me what range we would cast to for "unsigned shift"--if someone wants unsigned shift, they can produce a non-negative integer themselves, and then pass it into the universal shift operator. So therefore, in my mind, if we want to give >>> semantics, it would be the same as >>.

[lars-t-hansen]

A sensible meaning for >>> might be to compute the absolute value and then shift that. Plausibly an engine can implement that slightly faster than the user program, but I doubt it matters much. +1 on throwing for >>> until clear use cases appear.

[littledan]

@lars-t-hansen The absolute value semantics was also suggested by @rauschma , but it seems surprising to me. >>> could hypothetically have those semantics on Numbers too, but instead wraparound semantics were chosen. It seems surprising that (-1) >>> x would differ so much from (-1n) >>> x.

[rauschma]

I’ve since changed my mind, since negativity for BigInts is more like an orthogonal (out-of-band) flag and not directly encoded as a bit, as it is with a fixed amount of bits (e.g. 32 bits for JS Numbers).

[littledan]

OK, it still seems like there isn't a great meaning for >>>. It seems like we have good reason to keep the spec as it is, throwing on >>> for BigInts.