Repository navigation
Mention proposed integration with "structured cloning" #19
Description
It would be useful to know how this will interact with https://html.spec.whatwg.org/#safe-passing-of-structured-data. Transfer seems covered, but is immutability preserved when you copy?
Activity
erights commentedon Dec 23, 2024
Good question! I would like the answer to be "yes". This best satisfies the intuition that the thing received resembles the thing sent as much as practical.
Does anyone see a problem with that? If not, let's proceed on that basis and close this issue.
@annevk , would you like to suggest a corresponding revision to that whatwg doc? Would this be a whatwg PR? How should the connection between the two specs be coordinated?
annevk commentedon Jan 6, 2025
Typically when proposals reach stage 3 in TC39 corresponding WHATWG PRs are created. Either by the champions or those willing to help them. Tracking that here is probably useful so I would not close this quite yet.
bakkot commentedon Feb 7, 2025
Preserving immutability also allows implementations to avoid copying the data entirely, at least in some cases (such as when using
structuredClone).Also note that transferring an ArrayBuffer (as part of cloning) will detach it, and since these can't be detached, that implies they can't be transferred. That will require an explicit check, ideally before doing the rest of the transfers. Right now the HTML algorithm would detach the buffer in spite of it being immutable, because it calls DetachArrayBuffer directly and this proposal hasn't updated that AO to guard on immutability.
(I suppose they could be transferrable and have that just do a copy, but that's kind of weird.)
mhofman commentedon Feb 7, 2025
Given that transferable is an explicit opt-in from the sender, I don't think it makes sense to accept this case. Throwing and error seems more appropriate.
I'm surprised. What happens today when trying to transfer an ArrayBuffer that's already detached? There should be a check for that already, no?
Right that sounds like a bug the proposal needs to fix. Should the AO assert that the array buffer is not immutable, or should it throw a TypeError if it is immutable? Aka should it be the caller checking ahead of time or not?
mhofman commentedon Feb 7, 2025
Actually it sounds like the check would be in StructuredSerializeWithTransfer, which currently start as:
Would it make sense to omit the
[[Detached]]slot from immutable array buffers if they're not detachable?bakkot commentedon Feb 7, 2025
It throws; see StructuredSerializeWithTransfer step 5.1.
Either works in principle, but throwing is more likely to make consumers correct without needing any changes (though in this specific case they'd be throwing the wrong error type, and I don't know of any other consumers).
The
[[Detached]]slot is an HTML thing. We use a different mechanism which can't easily be omitted.gibson042 commentedon Feb 15, 2025
whatwg/html#11033
erights commentedon Feb 17, 2025
@annevk @bakkot , if you're satisfied by @gibson042 's whatwg/html#11033 , can we close this issue?
bakkot commentedon Feb 17, 2025
@erights There's more to do on that PR; I'd prefer we leave this open until we've actually gotten the full semantics of structured clone of immutable buffers worked out.
Also the readme of this proposal should link (and ideally describe the semantics of) that PR, so people can actually find it.
README: Reference HTML structuredClone integration
gibson042 commentedon Feb 17, 2025
@bakkot Updated whatwg/html#11033 , and opened #39 here to reference it.
README: Reference HTML structuredClone integration (#39)
bakkot commentedon Feb 17, 2025
I'm happy calling this completed now. Can be re-opened if anyone raises issues with the proposed structured clone semantics.
erights commentedon Feb 17, 2025
In light of @bakkot 's response, I'm closing this. @annevk , please reopen if you still have any blocking concerns. Thanks!