SameValueZero calls should probably be prefixed by ?

[domenic]

Let me know if I'm missing something. But my understanding is that SameValueZero can return an abrupt completion. Throughout the spec it is used as if it cannot, e.g. "If SameValueZero(numberLength, elementLength) is false, throw a RangeError exception."

Probably also ToNumber and ToString?

I am unclear what to do here for Array.prototype.includes, given the inconsistency.

[anba]

ReturnIfAbrupt and its ?-prefix form are only used when an abrupt completion can occur. Calling SameValueZero(numberLength, elementLength), where numberLength and elementLength are both number values, will never return an abrupt completion, so ReturnIfAbrupt gets omitted.

[anba]

ReturnIfAbrupt and its ?-prefix form are only used when an abrupt completion can occur. Calling SameValueZero(numberLength, elementLength), where numberLength and elementLength are both number values, will never return an abrupt completion, so ReturnIfAbrupt gets omitted.

[bterlson]

Just to add to what @anba says, choosing to omit ? should be a very deliberate choice - you're signaling implementers that the operation is not expected to result in an abrupt completion (or that you're working on completion values). Right now we have an ambiguity between those two cases so I am thinking we will want another operator (say, !) to mean assert you didn't get an abrupt completion and unwrap the completion record's value.

[bterlson]

Just to add to what @anba says, choosing to omit ? should be a very deliberate choice - you're signaling implementers that the operation is not expected to result in an abrupt completion (or that you're working on completion values). Right now we have an ambiguity between those two cases so I am thinking we will want another operator (say, !) to mean assert you didn't get an abrupt completion and unwrap the completion record's value.

[rossberg]

A serious problem with not having ? in cases like this is that it amounts to an implicit conversion from CompletionRecord to Value, by implicitly projecting .[[value]]. IMO, that is pretty bad and should be avoided in the spec. I already dislike the implicit injection in 6.2.2.2/3, but at least that is specified, whereas projection is not AFAICS. If you want to avoid ?, I think introducing ! for such cases is highly preferable.

[rossberg]

A serious problem with not having ? in cases like this is that it amounts to an implicit conversion from CompletionRecord to Value, by implicitly projecting .[[value]]. IMO, that is pretty bad and should be avoided in the spec. I already dislike the implicit injection in 6.2.2.2/3, but at least that is specified, whereas projection is not AFAICS. If you want to avoid ?, I think introducing ! for such cases is highly preferable.

[anba]

I already dislike the implicit injection in 6.2.2.2/3, but at least that is specified, whereas projection is not AFAICS.

Projection is also specified in 6.2.2.2:

Any reference to a Completion Record value that is in a context that does not explicitly require a
complete Completion Record value is equivalent to an explicit reference to the [[value]] field of the
Completion Record value unless the Completion Record is an abrupt completion.

[anba]

I already dislike the implicit injection in 6.2.2.2/3, but at least that is specified, whereas projection is not AFAICS.

Projection is also specified in 6.2.2.2:

Any reference to a Completion Record value that is in a context that does not explicitly require a
complete Completion Record value is equivalent to an explicit reference to the [[value]] field of the
Completion Record value unless the Completion Record is an abrupt completion.

[rossberg]

Ah, okay, thanks, I missed that. I think that should go into a separate section, or the section title should be renamed. (I'd still prefer avoiding implicit conversions in that direction altogether.)

[rossberg]

Ah, okay, thanks, I missed that. I think that should go into a separate section, or the section title should be renamed. (I'd still prefer avoiding implicit conversions in that direction altogether.)