Skip to content

README: Clean up Q&A #14

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 1 commit into from
Oct 10, 2024
Merged

README: Clean up Q&A #14

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
41 changes: 28 additions & 13 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,41 +111,54 @@ Tracking issues to be added:
## Q&A

<dl>
<dt>
<!-- Markdown rendering of HTML blocks requires a blank line before further Markdown content. -->

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

<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 the index properties of a TypedArray backed by an immutable ArrayBuffer be configurable and writable?
</dt>
<dd>
No, TypedArray index properties should continue to track the state of the underlying buffer without individual bookkeeping.
</dd>

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 the index properties of a TypedArray backed by an immutable ArrayBuffer be configurable and writable?

Should `transferToImmutable` support a _newByteLength_ argument?
</dt>
<dd>
It might be useful for truncation, but probably rarely for expansion because the output would have an all-zeroes suffix that could not be changed.
</dd>

No, TypedArray index properties should continue to track the state of the underlying buffer without individual bookkeeping.

<dt>

Should ArrayBuffers support zero-copy slices (e.g., `arrayBuffer.sliceToImmutable()`)?
</dt>
<dd>
https://github.com/tc39/proposal-immutable-arraybuffer/issues/9
</dd>


<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>

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>

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,
Expand All @@ -154,4 +167,6 @@ Similarly,
* And also for `Atomics` functions.

</dt>


<dl>
Loading