Unnecessary RequireObjectCoercible in String.prototype.matchAll

[anba]

https://tc39.es/ecma262/#sec-string.prototype.matchall, step 2.b.ii can be removed, because both null and undefined will also result in a TypeError in step 2.b.iii, because neither "null" nor "undefined" contain "g".

Explicitly listing the two allowed cases (Type(flags) is String or Type(flags) is Object) don't seem useful to me, therefore removing the complete step 2.b.ii is more in-line with the rest of the spec.

[ljharb]

I see what you're saying, but it doesn't make any sense to me to make that edge case implicit. I think we don't have a general rule that exception cases shouldn't be duplicated in this way; in this case, it means that the reader of matchAll doesn't have to think about what a nullish ToString is, nor figure out that it doesn't contain "g".

[anba]

But how is a nullish value different from, let's say a number or boolean value? Not having to figure out that neither null nor undefined contains "g" isn't different from not having to figure out that neither number nor boolean values contain "g", IMO.

[ljharb]

It seems useful to me to clearly distinguish in the spec between when a Get of "flags" produces a nullish value, versus when it produces an object that toStrings to a nullish value, even though it wouldn't necessarily be observable which one (although an implementation may wisely choose to provide better error messages for the different cases, regardless of whether that step is present or not).

[anba]

[...], versus when it produces an object that toStrings to a nullish value, [...]

I don't understand this part. ToString never returns a nullish value.

[ljharb]

ToString does not; toString may.

{ toString() { return null; } }

[anba]

Returning null or "null" from toString() is indistinguishable from String.prototype.matchAll, so I don't see how this matters for this issue.

[ljharb]

Observably, you’re right - but i meant as a spec reader, it feels useful to me to convey the distinction without having to reason through the entire algorithm.

[ljharb]

(I particularly feel this way because of the confusion when creating es6 that led to the regex symbol methods incorrectly stringifying undefined instead of matching the RegExp constructor and converting it to the empty string; i did not want to see undefined flags stringified here to repeat the mistake)

[littledan]

I'm pretty confused by this thread. Can't we use assertions or notes for this sort of purpose that @ljharb is getting at?

[ljharb]

In this case, we couldn't use an assertion because an object that toStrings to null/undefined is valid; we could use a note, but that seems less clear to me - in either case, the observable behavior is the same (modulo error messages which remain up to the implementation) so it seems like it comes down to a subjective readability preference.

[bakkot]

It seems weird to me to distinguish null and undefined but not true, false, or numerics. I would be happier either listing the two allowed cases (which is future-proof against introducing new primitives which can ToString to something with a g), or eliminating the assert entirely (and perhaps replacing it with a Note that the only types for which you will not necessarily get a TypeError are Object and String).