Open anba opened 1 week ago
Hm. 262 uses RangeError almost exclusively for numeric arguments. We don't have many positions which take a limited set of strings, but for example Date.prototype[Symbol.toPrimitive]
takes one of "string", "number", or "default", and throws a TypeError, not a RangeError, if given some other value.
I would prefer not to have two different error kinds here. I don't know whether it's worth breaking with 402, though. On the other hand, 402 and Temporal also do coercion of arguments, which we're no longer doing.
(Your observation applies equally to the stage-3 base64 proposal, incidentally.)
Personally, I definitely would find it more intuitive for an invalid enum value to throw a RangeError, since it's not the type that's wrong, it's that it's not in the set of allowed values.
Uh. I don't know what "type" means if not "the set of allowed values".
lol i shouldn't have used the word "set" then - it's not in the finite list of allowed values maybe?
A lot of types are finite lists? Boolean is just the two values true
and false
, e.g.
"These three specific strings" is no more or less of a type than "all strings". (For example TypeScript will let you represent that type just fine; I expect the types it will add for this proposal will reflect that.)
RangeError
description also mentions "set or range of allowable values" → https://tc39.es/ecma262/#sec-native-error-types-used-in-this-standard-rangeerror.
I guess String.prototype.normalize is the counterexample where ECMA-262 uses a RangeError
for an invalid string.
Looking elsewhere, the web platform has a number of methods which take enums (parseFromString
, Request
/fetch
's method
), setTextRange
, etc) and the modern handling for invalid values is always to throw a TypeError, though some legacy stuff does something different (e.g. insertAdjacentHTML
throws a SyntaxError
).
Iterator.zip and Iterator.zipKeyed, step 5:
Temporal and ECMA-402 both throw a
RangeError
for invalid options:Maybe consider changing step 5 to: