Skip to content

README: Add (and answer) question about immutableArrayBuffer.transfer() #5

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Oct 4, 2024
Merged

README: Add (and answer) question about immutableArrayBuffer.transfer() #5

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
92f7774
README: Refactor Q&A into a <dl>
gibson042 Oct 3, 2024
4a264f2
README: Add (and answer) question about immutableArrayBuffer.transfer()
gibson042 Oct 3, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 35 additions & 7 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,10 +68,38 @@ Tracking issues to be added:

## Q&A

* Should `transferToImmutable` support a `newByteLength` argument?
* 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.
<dl>
<dt>

Why can't an immutable ArrayBuffer be detached/transferred?

</dt>
<dd>

Because that would result in observable changes to any TypedArray or DataView backed by it.

</dd>
<dt>

Should `transferToImmutable` support a `newByteLength` argument?

</dt>
<dt>

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?

</dt>
<dt>

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.

</dt>
<dt>

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.

</dt>
<dl>
Loading