generated from tc39/template-for-proposals
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Order of operations, when to throw or silently do nothing? #16
Comments
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. |
Open
erights
added a commit
to endojs/endo
that referenced
this issue
Jan 13, 2025
Closes: tc39/proposal-immutable-arraybuffer#26 Refs: https://github.com/tc39/proposal-immutable-arraybuffer tc39/proposal-immutable-arraybuffer#15 tc39/proposal-immutable-arraybuffer#9 tc39/proposal-immutable-arraybuffer#16 ## Description Since the last work on this immutable-arraybuffer shim, at the tc39 plenary we decided that - `transferToImmutable` should take an optional `newLength` parameter, to stay parallel to the other `transfer*` methods. - The `sliceToImmutable` method should be added. The spec at https://github.com/tc39/proposal-immutable-arraybuffer and the Moddable XS implementation both already reflect these changes. This PR brings this shim up to date with those changes, closing tc39/proposal-immutable-arraybuffer#26 ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations The proposal's draft spec has already been updated. ### Testing Considerations New tests lightly test the new functionality. The code and tests may differ from the current draft spec on order of operations and errors thrown. But since these issues are purposely still open tc39/proposal-immutable-arraybuffer#16 , this divergence is not yet a big deal. ### Compatibility Considerations No more than the baseline shim already on master. ### Upgrade Considerations No production code yet depends on this shim. So, none.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Originally:
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.
The text was updated successfully, but these errors were encountered: