Is `GetOptionsObject` really required?

[zloirock]

Sure, it's an unobservable operation and can be avoided in implementations, but it makes the spec more difficult and can be replaced with 1 undefined check in one method and 2 in another.

[bakkot]

It's a method used in a number of other specs, including 402 and Temporal. It could be removed throughout, but I'm prioritizing consistency for the moment.

Incidentally if you're implementing this you may want to hold off. It's only stage 2 and the API is likely to change before stage 3.

[zloirock]

Incidentally if you're implementing this you may want to hold off. It's only stage 2 and the API is likely to change before stage 3.

Yes, I'm implementing it and understand that it's on stage 2 and most likely will be changed, but it's a polyfill for familiarization and experiments with this future API, not for production. Now early stage APIs are significantly fenced off from stable in core-js and they will be fenced off even more in the future to prevent possible errors associated with this.

[ljharb]

Consistency and avoiding future behavior drift is much more important than spec complexity imo.

[zloirock]

Consistency

So, it's inconsistent with current ES spec cases - for example, Error options (with cause) case.

[ljharb]

cause is a uniquely special case that is intentionally different from everything else, because you can have a nullish cause of an exception.

[zloirock]

It is about options argument case and definitely not about cause.

Anyway, I don't care - GetOptionsObject looks like a good internal abstraction, but it seems similar spec cases should be refactored for consistency -)

[ljharb]

I'm sure they will once the AO first lands in 262, but it's not there yet.

[bakkot]

it seems similar spec cases should be refactored for consistency

Yeah, things are in a kind of strange state right now because 402, Temporal, and lots of other proposals use options bags, and have mostly copy-pasted that AO around, but the only thing in 262 which uses an options bag is Error, and Error is weird for other reasons. The trouble with Error, if I recall correctly, is that some engines have a non-standard extension which allows specifying a line number or file name or something in the same position as the spec now uses for the options argument, so it would probably not be web-compatible to throw an error when the user passes a number or string in that position. So Error needs to silently ignore non-object values passed in that position.

But new things (e.g. this API) don't have that legacy constraint, so they can throw if you pass a non-object value instead of silently ignoring it, and so all new things use (or at least should use) GetOptionsObject.

[bakkot]

This can be further refined when landing in 262, but I think we're going to want something like this across many proposals. Closing as answered.