Order of operations, when to throw or silently do nothing?

[erights]

• Should sliceToImmutable with reversed start and end throw an exception even though slice with the same arguments would not?

• Should trying to write data in an immutable ArrayBuffer via a TypedArray element set throw, even though trying to write out-of-bounds or to a detached ArrayBuffer does not?

• Should TypedArray write methods (copyWithin, fill, reverse, set, etc.) throw when their backing ArrayBuffer is immutable but the targeted range is zero-length? If so, how early or late in the algorithm? The methods currently inspect arguments after ValidateTypedArray.

Similarly,

• How early or late in SetViewValue against an immutable ArrayBuffer should an exception be thrown? It currently inspects arguments before IsViewOutOfBounds.

• Likewise for abstract operations such as ArrayBufferCopyAndDetach (which currently checks IsSharedArrayBuffer, then newLength, then IsDetachedBuffer).

• And also for Atomics functions.

[erights]

To be driven by implementor feedback.

But my general inclination is: when in doubt, throw.

Moddable XS implementation throws.

Looking for further implementation feedback, both regarding throwing, and any other observable order-of-operation questions.

[gibson042]

Tentative resolutions as reflected in spec text and testing plan as of 2025-05-29:

Should sliceToImmutable with reversed start and end throw an exception even though slice with the same arguments would not?

No

9. Let _newLen_ be max(_final_ - _first_, 0).

Should trying to write data in an immutable ArrayBuffer via a TypedArray element set throw, even though trying to write out-of-bounds or to a detached ArrayBuffer does not?

Yes.

1.b.ii. If IsImmutableBuffer(_O_.[[ViewedArrayBuffer]]) is *true*, return *false*.

Should TypedArray write methods (copyWithin, fill, reverse, set, etc.) throw when their backing ArrayBuffer is immutable but the targeted range is zero-length? If so, how early or late in the algorithm? The methods currently inspect arguments after ValidateTypedArray.

Yes, before touching arguments.

2. Let _taRecord_ be ? ValidateTypedArray(_O_, ~seq-cst~, ~write~).

How early or late in SetViewValue against an immutable ArrayBuffer should an exception be thrown? It currently inspects arguments before IsViewOutOfBounds.

Immediately after validating the receiver as a DataView.

3. If IsImmutableBuffer(_view_.[[ViewedArrayBuffer]]) is *true*, throw a *TypeError* exception.

Likewise for abstract operations such as ArrayBufferCopyAndDetach (which currently checks IsSharedArrayBuffer, then newLength, then IsDetachedBuffer).

ArrayBufferCopyAndDetach affects ArrayBuffer.prototype.{transfer,transferToFixedLength,transferToImmutable}, and this is indeed awkward. The mutability check immediately follows the non-detachment check.

6. If IsImmutableBuffer(_arrayBuffer_) is *true*, throw a *TypeError* exception.

And also for Atomics functions.

The first throwable step of AtomicReadModifyWrite and sibling algorithms in Atomics.compareExchange and Atomics.store is ValidateAtomicAccessOnIntegerTypedArray with accessMode=~write~, whose own first throwable step is RequireInternalSlot(O, [[TypedArrayName]]) in ValidateTypedArray. And the mutability check immediately follows.

4. If _accessMode_ is ~write~ and IsImmutableBuffer(_O_.[[ViewedArrayBuffer]]) is *true*, throw a *TypeError* exception.