Editorial: Fixed mutable completion records as immutable

[jhnaldo]

In my understanding, the common practice for completion records is to use them as immutable records. For example, 6.2.4.3 UpdateEmpty does not directly modify the [[Value]] field but creates another completion record having the given value in the [[Value]] field.

However, step 7.c.iii.2 in the 15.5.5 Runtime Semantics: Evaluation for <emu-grammar>YieldExpression : `yield` `*` AssignmentExpression</emu-grammar> breaks this common practice. I think this is the only step that treats completion records as mutable in the spec.

In addition, as mentioned in es-meta/esmeta#65, we found that only three Test262 tests related to this issue:

• language/expressions/async-generator/yield-star-getiter-async-return-method-is-null.js
• language/statements/async-generator/yield-star-return-then-getter-ticks.js
• language/statements/async-generator/yield-star-return-missing-value-is-awaited.js

So, I modified step 7.c.iii.2 in the 15.5.5 Runtime Semantics: Evaluation to introduce a new completion record instead of updating its [[Value]] field.

[bakkot]

Editors are fine with this, but we do want to say explicitly that mutating record fields in general isn't something we want to get rid of. Completion records are a bit special, though.

[jhnaldo]

Editors are fine with this, but we do want to say explicitly that mutating record fields in general isn't something we we ant to get rid of. Completion records are a bit special, though.

I totally agree with you. Mutating record fields is a common practice in general, but completion records are special ones that can be used in every place to represent control flows. I think it is better to disallow mutating completion records to prevent unexpected side effects because of the mutability.