Should transferToImmutable support a newByteLength argument?
#15
Assignees
Comments
|
I find the "Minimize consequences of reasonable surprise" argument the most compelling, so I'm inclined towards including this parameter. This would involve a change to the spec and shim as currently (1 dec 2024) written. The Moddable XS implementation already implements this parameter, and so would not need to change. If tc39 agrees, I'll close with this decision. |
transferToImmutable support a _newByteLength_ argument?transferToImmutable support a _newByteLength_ argument?
transferToImmutable support a _newByteLength_ argument?transferToImmutable support a newByteLength argument?
gibson042
added a commit
to gibson042/tc39-proposal-immutable-arraybuffer
that referenced
this issue
Dec 3, 2024
gibson042
added a commit
to gibson042/tc39-proposal-immutable-arraybuffer
that referenced
this issue
Dec 3, 2024
This was referenced Dec 5, 2024
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
In favor: Least surprise. Minimize consequences of reasonable surprise. If we add this parameter, those who expect it not to be there and don't provide such an argument get what they expect anyway. OTOH, if we omit it, those who expect it to be there and provide such an argument do not get either a static or dynamic diagnostic. Rather, the code proceeds to silently do something other than they expect.
Against: 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.
Both sides can also make arguments from orthogonality:
transfer*operations.The text was updated successfully, but these errors were encountered: