Mention proposed integration with "structured cloning"

[annevk]

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?

[erights]

is immutability preserved when you copy?

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]

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]

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]

(I suppose they could be transferrable and have that just do a copy, but that's kind of weird.)

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.

That will require an explicit check, ideally before doing the rest of the transfers.

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?

it calls DetachArrayBuffer directly and this proposal hasn't updated that AO to guard on immutability.

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]

Actually it sounds like the check would be in StructuredSerializeWithTransfer, which currently start as:

For each transferable of transferList:

1. If transferable has neither an [[ArrayBufferData]] internal slot nor a [[Detached]] internal slot, then throw a "DataCloneError" DOMException.
2. If transferable has an [[ArrayBufferData]] internal slot and IsSharedArrayBuffer(transferable) is true, then throw a "DataCloneError" DOMException.

Would it make sense to omit the [[Detached]] slot from immutable array buffers if they're not detachable?

[bakkot]

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?

It throws; see StructuredSerializeWithTransfer step 5.1.

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?

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

Would it make sense to omit the [[Detached]] slot from immutable array buffers if they're not detachable?

The [[Detached]] slot is an HTML thing. We use a different mechanism which can't easily be omitted.

[gibson042]

whatwg/html#11033

[erights]

@annevk @bakkot , if you're satisfied by @gibson042 's whatwg/html#11033 , can we close this issue?

[bakkot]

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

[gibson042]

@bakkot Updated whatwg/html#11033 , and opened #39 here to reference it.

[bakkot]

I'm happy calling this completed now. Can be re-opened if anyone raises issues with the proposed structured clone semantics.

[erights]

In light of @bakkot 's response, I'm closing this. @annevk , please reopen if you still have any blocking concerns. Thanks!