Atomic ops range checking should follow DataView and SIMD ops, not indexing operation

[lars-t-hansen]

The SIMD spec is trying to clean up the range checking for its function-like accessors and there has been a discussion about what the semantics should be. The SIMD spec wants to follow the function-like operations on DataView, in this regard, ie, convert by ToNumber and then by ToInteger and then do some fairly simple checking after that which will conflate -0 and +0 and also allow strings like " 0x37" (note the space and the hex) to be used as indices (in this case meaning 55) because ToNumber does the conversion.

At the moment the shared memory spec instead implements the range checking as in the indexing operations of the language, going the ToPropertyKey / CanonicalNumericIndex route, see here. For the two specs to diverge on this point is not ideal, so let's agree.

The SIMD cabal's argument is that as there is already a pattern in the language for how to convert arguments in these function-like operations, we should follow that pattern, even if strictly speaking the type and range checking of the indexing operator is tighter. I've decided to buy that argument.

cc @littledan @stoklund @PeterJensen @binji

[lars-t-hansen]

Tracking bug for Firefox: https://bugzil.la/1253370

[binji]

Probably a dumb question, but what exactly does ≠ mean in this context? (https://tc39.github.io/ecmascript_sharedmem/shmem.html#Atomics.ValidateAtomicAccess step 5)

[lars-t-hansen]

It should mean "not equal to".

[binji]

Well, right. :) I mean how is the comparison done? Are any conversions done?

[lars-t-hansen]

Ah, I see :) No conversion should be necessary. ToInteger returns a double, like ToNumber.

[binji]

OK, that makes sense. Thanks!