-
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
add .sliceToImmutable
?
#9
Comments
FWIW –
|
Ah, nice, sorry I missed that. I'll leave this open as a place to track for now. |
In addition to @bakkot 's argument, an additional reason to add this is that there's otherwise(*) no way to make a zero-copy immutable slice of an immutable arrayBuffer. Without (*) Under the normal implementation assumption that implementations do not attempt heroics like a copy-on-write implementation. I currently favor adding this operation. If tc39 agrees, I will close with that decision. |
At the December tc39 plenary, tc39 did agree. However, I'll leave this issue open until the spec text in this repo is revised accordingly. |
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.
In many use cases you want to take a snapshot of some mutable data. The snapshot should be immutable, but the original data remains mutable.
Right now, that requires two steps:
mutable.slice(0).transferToImmutable()
. In practice I would guess that the intermediate mutable copy is quite cheap. But it may be worth checking this assumption with engines to verify this, because if the intermediate mutable copy is actually expensive, it could be worth adding another method to combine these steps into one.The text was updated successfully, but these errors were encountered: