Editorial: make NumberBitwiseOp, BigIntBitwiseOp, ByteListBitwiseOp consistent
#1998
Conversation
|
I prefer the token to the string. It feels like a bit less indirection to me. |
|
Like |
|
Yeah. |
ljharb
force-pushed
the
bitwise_consistency
branch
from
bc2a813 to
e530532
Compare
|
@michaelficarra updated! |
ljharb
force-pushed
the
bitwise_consistency
branch
from
e530532 to
8dfcc0f
Compare
ljharb
force-pushed
the
bitwise_consistency
branch
from
8dfcc0f to
732a115
Compare
|
@ljharb In 12.15.6 (Runtime Semantics: EvaluateStringOrNumericBinaryExpression), we describe the I also don't like how (as far as I can tell) we don't explicitly say anywhere that, for example,
Do we actually say anywhere that |
|
I believe we’re just supposed to infer it, which I’m not happy with either. I’ll update 12.15.6 for sure; in the meantime, I’d either be happy to take a suggestion for how to specify this stuff better in this PR, or also to do it in a followup so that this one can at least remove a bunch of inconsistency. |
|
@michaelficarra hmm, i'm actually not sure how to update 12.15.16 without solving that larger problem. Would you be OK with flipping this PR back to using strings, and then in a followup, we can tackle the larger issue of how these are defined and specified? |
ljharb
force-pushed
the
bitwise_consistency
branch
from
732a115 to
6cece8f
Compare
ljharb
force-pushed
the
bitwise_consistency
branch
from
6cece8f to
267e674
Compare
ljharb
force-pushed
the
bitwise_consistency
branch
from
267e674 to
9fa1760
Compare
…eOp` consistent Ensure `op` is a token in all cases, and ensure all three operations assert on the contents of `op`. Fixes tc39#1989.
| <h1>ByteListBitwiseOp( _op_, _xBytes_, _yBytes_ )</h1> | ||
| <p>The abstract operation ByteListBitwiseOp takes arguments _op_ (a read-modify-write modification function), _xBytes_ (a List of byte values), and _yBytes_ (a List of byte values). The operation atomically performs a bitwise operation on all byte values of the arguments and returns a List of byte values. It performs the following steps when called:</p> | ||
| <h1>ByteListBitwiseOp ( _op_, _xBytes_, _yBytes_ )</h1> | ||
| <p>The abstract operation ByteListBitwiseOp takes arguments _op_ (a sequence of Unicode code points), _xBytes_ (a List of byte values), and _yBytes_ (a List of byte values). The operation atomically performs a bitwise operation on all byte values of the arguments and returns a List of byte values. It performs the following steps when called:</p> |
There was a problem hiding this comment.
Oops, good catch and thanks for fixing.
Ensure
opis a String in all cases, and ensure all three operations assert on the contents ofop.Previously,
NumberBitwiseOpandByteListBitwiseOpdid not assert onop, and they were passing an operator as if it was a first-class value. Instead, I made all three use the approach ofBigIntBitwiseOp.An alternative to strings would be to use
~^~etc; happy to switch them all to that form if that's preferred.