Skip to content
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

Closed
bakkot opened this issue Oct 10, 2024 · 4 comments · Fixed by #21
Closed

add .sliceToImmutable? #9

bakkot opened this issue Oct 10, 2024 · 4 comments · Fixed by #21

Comments

@bakkot
Copy link

bakkot commented Oct 10, 2024

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.

@phoddie
Copy link
Collaborator

phoddie commented Oct 10, 2024

FWIW – sliceToImmutable() is included in @erights' slides in the Open Questions section.

sliceToImmutable(start?: number, end?: number) :ArrayBuffer

@bakkot
Copy link
Author

bakkot commented Oct 10, 2024

Ah, nice, sorry I missed that. I'll leave this open as a place to track for now.

@gibson042 gibson042 changed the title add .copyToImmutable? add .sliceToImmutable? Oct 10, 2024
@erights
Copy link
Collaborator

erights commented Dec 1, 2024

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 sliceToImmutable, the code (similar to @bakkot 's example) would be immutable.slice(s,e).transferToImmutable(), which would have a hard time avoiding an intermediate mutable copy.

(*) 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.

@erights
Copy link
Collaborator

erights commented Dec 23, 2024

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.

gibson042 added a commit to gibson042/tc39-proposal-immutable-arraybuffer that referenced this issue Dec 25, 2024
gibson042 added a commit to gibson042/tc39-proposal-immutable-arraybuffer that referenced this issue Dec 26, 2024
gibson042 added a commit to gibson042/tc39-proposal-immutable-arraybuffer that referenced this issue Dec 26, 2024
gibson042 added a commit to gibson042/tc39-proposal-immutable-arraybuffer that referenced this issue Dec 26, 2024
gibson042 added a commit to gibson042/tc39-proposal-immutable-arraybuffer that referenced this issue Dec 28, 2024
gibson042 added a commit to gibson042/tc39-proposal-immutable-arraybuffer that referenced this issue Jan 9, 2025
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
Labels
None yet
Projects
None yet
3 participants