Handle of private fields in the structured cloning

[petamoriken]

Ref: tc39/ecma262#1668

In current spec, all objects have an internal slot named [[PrivateElements]]. It is not allowed in the structured cloning.

22. Otherwise, if value has any internal slot other than [[Prototype]] or [[Extensible]], then throw a "DataCloneError" DOMException.

Additional: Perhaps a DataCloneError should be thrown for objects with private properties or accessors, but that is a breaking change.

[annevk]

What do implementations do today?

@bakkot @ljharb @syg perhaps we can figure out a more suitable primitive in JavaScript to use instead here? Maybe something like "IsBasicObject" or "HasBasicObjectInternalSlots"?

[ljharb]

I would assume that you'd want to ignore any [[PrivateElements]] slot that's empty.

Since objects in the spec don't get slots dynamically added, i guess we would indeed need an AO if you wanted 262 to own the logic - but i'm not sure that's ideal given that HTML can add its own slots, as can 402.

[annevk]

Hopefully neither HTML nor 402 would add a slot to all objects without changing 262? As for the logic we need, I'm not sure, but we shouldn't reveal whether or not an object has private elements, I'd think.

[ljharb]

I completely agree that should not be revealed.

Doesn't that mean though that an object's private elements should be ignored, since literally any object (i think? maybe only those with a mutable [[Prototype]]) could have private fields installed on it with the super return override trick, not just instances of classes with private fields defined?

[annevk]

Yeah, that would mean adding [[PrivateElements]] to the list of [[Prototype]] and [[Extensible]] in step 22 quoted in OP. The remaining question is then whether 262 should maintain the logic of that step so that if a new slot is added to basic objects, HTML doesn't need a change there.

[ljharb]

Gotcha. I’ll defer to the editors to decide that, but it seems both very rare, and also, like the behavior of such a ubiquitous slot would need to be considered case-by-case in structured cloning anyways, so I’m not sure there’s an advantage to 262 maintaining a list (of course, if someone were to drive structured cloning as a language proposal directly, that might obviate the concern ;-) )

[syg]

What do implementations do today?

V8 compiles private fields internally to special symbol keys on objects, and the implementation of structured cloning ignores all non-String-keyed own properties. IOW private fields are ignored.

@bakkot @ljharb @syg perhaps we can figure out a more suitable primitive in JavaScript to use instead here? Maybe something like "IsBasicObject" or "HasBasicObjectInternalSlots"?

It slipped the last meeting, but I'm bringing up the topic of moving structured clone maintenance over to ecma262 at the next meeting. So my answer here is let the ecma262 editors worry about it. :)