You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note this clarification text has been added to the spec regarding interpretation of variable bindings for record, list, and other complex specification types:
Algorithm steps may declare named aliases for any value using the form “Let x be someValue”. These aliases are reference-like in that both x and someValue refer to the same underlying data and modifications to either are visible to both. Algorithm steps that want to avoid this reference-like behavior should explicitly make a copy of the right-hand side: “Let x be a copy of someValue” creates a shallow copy of someValue.
This was added in response to my clarification request in tc39/ecma262#752 noting that my interpretation of the behaviour of CompletePropertyDescriptor and its usage in [[GetOwnProperty]] for Proxy objects.
I imagine that to guarantee correctness and closeness to the spec in the future, we're going to need to adjust jsexplain's heap structure to match this.
The text was updated successfully, but these errors were encountered:
Note this clarification text has been added to the spec regarding interpretation of variable bindings for record, list, and other complex specification types:
This was added in response to my clarification request in tc39/ecma262#752 noting that my interpretation of the behaviour of
CompletePropertyDescriptor
and its usage in[[GetOwnProperty]]
for Proxy objects.I imagine that to guarantee correctness and closeness to the spec in the future, we're going to need to adjust jsexplain's heap structure to match this.
The text was updated successfully, but these errors were encountered: