Should shifts of BigInt by Number be allowed?

[msaboff]

In section 4.6, all shift operators require that Type(lnum) be the same as Type(rnum). It seems to me that the shift amounts are likely to be easily representable as Numbers and it seems cumbersome to write
let x = someValue << 2n
based on what type someValue is.

[littledan]

I've gone back and forth on this. Initially, Brendan and I were talking about arguments being uniform, until we noticed this ergonomics issue. It seemed to us that the right argument of shifts should be a Number. Brendan mentioned this in his Int64 proposal in November. However, when I was looking at the interaction with more numerically-oriented JS code, it seemed like it would be good to maintain the invariant that expressions like n << 0 always returns a Number in a particular range. I'd be OK with flipping back again, though--we don't maintain any such property with unary negate.

[littledan]

We discussed this issue at the May 2017 TC39 meeting, and I believe the conclusion was to leave the specification as it was, disallowing shifting by Numbers.

[littledan]

Jakob Kummerow (V8 team) raised this issue again. It also applies to exponentiation. If more and more people think it was a weird choice, I want to reopen this issue to confirm that we're not going the wrong way here.

[ajklein]

@jakobkummerow

[jakobkummerow]

My pragmatic observation is that there is no need to express bigger-than-int32 shift amounts, because realistically every implementation will have a limit on how big BigInts can be. In other words, under the hood an implementation will perform an implicit conversion of the shift amount from BigInt to plain old integer anyway -- and given that, passing in a Number directly seems more efficient. I also find it more natural: while operations like "add" and "multiply" clearly operate on two Numerics and as such can reasonably demand that those two inputs have the same type, it's different for operations like "{left,right}Shift" and "exponentiate", which conceptually operate on one Numeric, and take an additional parameter describing in more detail what exactly they do with this operand.

Anyway, I don't feel strongly about this. On the flip side, if the "shift amount" parameter is a BigInt, then at least we don't have to deal with Object-to-Number conversions and Double-to-Int32 truncations...

[littledan]

We discussed this question at the September 2017 TC39 meeting. The conclusion now is to keep the specification as is and make shift take a BigInt as the right parameter.