don't automatically initialise all internal slots to undefined

[michaelficarra]

We need to clean up how we create objects and set initial values of their internal slots. It is a common pattern today to call OrdinaryCreateFromConstructor with a list of additional slot names and then in the immediately following steps, set the initial values of each of these additional fields. But technically according to 6.1.7.2 Object Internal Methods and Internal Slots, these slots are given the value undefined in the interim.

Unless specified otherwise, the initial value of an internal slot is the value undefined.

This means that the declared type of each of these internal slots is implicitly unioned with undefined. We should instead create these slots and give them their initial values atomically, then remove this provision.

See related #3383.

[syg]

Recap of editor call:

• Let's change MakeBasicObject to take anonymous records of { [[SlotName]]: initialValue } "templates"
• Do the exercise of changing the callers to use the new form, which hopefully naturally points out where currently the initialization is already too far away from the allocation

[michaelficarra]

And of course remove the implicit initialisation affordance.

[bakkot]

MakeBasicObject is used upstream, at least in WebIDL but plausibly also other specs, so this will take at least a little integration work.

[michaelficarra]

There's a related issue here in that there may be an invariant that is stated in terms of 2 or more slots, such that there is no way to change the value of 1 slot at a time without violating the invariant between steps. The slots would need to be atomically set in the same way we need to atomically set them as we are initialising an object. Maybe our solution should cover both of these use cases?

[bakkot]

We should just violate the invariant between execution of those two steps.

[ljharb]

Or, alternatively, use one slot with a Record in it instead of two separate slots?

[michaelficarra]

@bakkot If we were okay with that kind of sloppiness, I don't see why we wouldn't be okay with the sloppiness in the OP: just create the object without specifying the values of the slots and then populate the slots afterward. I'm personally not okay with that kind of sloppiness though. I think this is a worthwhile problem to solve.

@ljharb That's reasonable though unfortunate that we have to refactor the data because we have no spec facility for atomic assignment. Another option would be to just do multiple assignments in one step and say the spec invariants only hold between any two steps.

[bakkot]

A proposal: remove the line about slots being initially undefined (including #3537), and change all the places where we initialize a slot using the wording "Set obj.[[slot]] to value" to instead use the wording "Initialize obj.[[slot]] to value". That will hopefully make it less likely that a later refactoring will move the initialization of the slot away from its creation.

(Right now at least [[GeneratorContext]] is initialized pretty far from its creation, which is annoying, as mentioned in #3482.)