Open ljharb opened 2 years ago
Thanls @ljharb - much appreciated.
why does ToPrimitive have a fast path for Records, but not also for Tuples? (i understand that the lack of a Record prototype is why it's needed for Records)
Yes the lack of prototype on Record exotic objects and it being frozen requires ToPrimitive
to explicitly handle them in some way otherwise it is a TypeError
. Tuple exotic objects having a prototype don't have this requirement. I'll open an issue to discuss if they should align with Record instead of the existing primitives. #350
Tuple [[HasProperty]]/[[Get]]: The GetPrototypeOf() step. I think this could return null, in which case the next line seems invalid. should that be checked for?
Right now the Tuple exotic object is non-extensible and always created with %Tuple.prototype%.
so GetPrototypeOf
can't return null.
@acutmore then why the ?
if it can't throw, and why would Tuple.prototype
's [[HasProperty]]
be able to throw?
Yep the completion handling isn’t right, likely a typo rather than intentional. I was only referring to why a null
prototype isn’t handled.
In that case I think it would be appropriate to add an Assert there that the value is Tuple.prototype.
Adding an assertion makes total sense, I like it.
!
~empty~
so that they're called withPerform
, to make it clear they're mutatingSameValueNonNumericScalarPrimitive
is a bit long thox
OrdinaryObjectCreate(null, « [[RecordData]] »)
instead of directly calling MakeBasicObject~empty~
?null
, in which case the next line seems invalid. should that be checked for?OrdinaryObjectCreate(%Tuple.prototype%, « [[TupleData]] »
instead of directly calling MakeBasicObjectI also filed #347 and #348.