Editorial: Treat not present parameters as undefined

[shvaikalesh]

Using missing parameters directly eliminates extra steps, resulting in more descriptive variable names and increased visibility for functions where "X is (not) present" is absolutely required. ES6+ era algorithms already do treat missing parameters as undefined and use them directly.

[zenparsing]

I don't think we can currently assume that "not present" is equivalent to "undefined" for abstract operations.

[bterlson]

This is correct, however I would be open to some clause 5 changes to make this work for abstract ops. I was also confused by this pattern until Allen explained it to me some years ago.

[jmdyck]

@shvaikalesh

resulting in more descriptive variable names

I don't understand this claim. Can you give an example?

[shvaikalesh]

@jmdyck

That claim was regarding e3f2a97: thisArg is more descriptive than T.

[jmdyck]

@shvaikalesh: Ah, thanks. I agree that thisArg is more descriptive than T.

Alternatively, one can avoid introducing T by replacing steps of the form:
If _thisArg_ is present, let _T_ be _thisArg_; else let _T_ be *undefined*.
with:
If _thisArg_ is not present, set _thisArg_ to *undefined*.

[jmdyck]

I'm guessing these changes are predicated on the paragraph in Clause 17 that says:

Unless otherwise specified in the description of a particular function, if a built-in function or constructor is given fewer arguments than the function is specified to require, the function or constructor shall behave exactly as if it had been given sufficient additional arguments, each such argument being the undefined value.

However, note the phrase "fewer arguments than the function is specified to require". Now, the number of arguments that a function "requires" isn't really defined, but a plausible meaning is the "default argument count" (i.e., the default value for the length property) defined a few paragraphs later. Note:

Optional parameters (which are indicated with brackets: [ ]) or rest parameters (which are shown using the form «...name») are not included in the default argument count.

On this basis, the "missing -> *undefined*" equivalence is not specified to hold for optional parameters. Algorithms for built-in functions are obliged to explicitly handle missing arguments for optional parameters (typically via "is [not] present").

So I think the changes of this PR are justified for non-optional parameters, but not for optional parameters.

[michaelficarra]

@shvaikalesh Can you add wording to the Notational Conventions section to address the concerns of @zenparsing and @bterlson (and me) above?

edit: I see that this change now only includes parameters for EcmaScript functions, not abstract operations.

[shvaikalesh]

On this basis, the "missing -> undefined" equivalence is not specified to hold for optional parameters. Algorithms for built-in functions are obliged to explicitly handle missing arguments for optional parameters (typically via "is [not] present").

Without this change, there are quite a few methods and constructors that assume "missing -> undefined" equivalence for optional parameters:

Complete list (22 functions, 25 parameters)

1. String.prototype.endsWith, endPosition at step 7
2. String.prototype.includes, position at step 6
3. String.prototype.indexOf, position at step 4
4. String.prototype.lastIndexOf, position at step 4
5. String.prototype.padEnd, fillString at step 2
6. String.prototype.padStart, fillString at step 2
7. String.prototype.startsWith, position at step 6
8. Array.from, mapfn at step 2
9. Array.prototype.copyWithin, end at step 7
10. Array.prototype.fill, start at step 3 and end at step 5
11. Array.prototype.flat, depth at step 4
12. Array.prototype.includes, fromIndex at step 4
13. Array.prototype.indexOf, fromIndex at step 4
14. Symbol, description at step 2
15. SharedArrayBuffer, length at step 2
16. DataView, byteOffset at step 3
17. %TypedArray%, byteOffset at step 6
18. %TypedArray%.prototype.copyWithin, end at step 8
19. %TypedArray%.prototype.fill, start at step 6 and end at step 8
20. %TypedArray%.prototype.set, offset at step 5
21. JSON.parse, reviver at step 7
22. JSON.stringify, replacer at step 4 and space at step 5

Are Clause 17 changes welcome?

[jmdyck]

This PR bumps up against some places in the current spec that are odd/underspecified (including the point I raised earlier), but I'll grant that it's not this PR's responsibility to resolve those problems.

The PR title and/or commit message should probably clarify that this is only dealing with parameters of built-in functions.

[jmdyck]

(It's odd to check if _value_ is present when _value_ isn't marked as optional, but the current spec has an analogous oddity.)

[michaelficarra]

I don't think it's odd. It's a mandatory parameter (Number.length is 1), and Number() is different than Number(void 0).

edit: Also, it's necessary to make an exception to the requirement you mentioned above:

Unless otherwise specified in the description of a particular function, if a built-in function or constructor is given fewer arguments than the function is specified to require, the function or constructor shall behave exactly as if it had been given sufficient additional arguments, each such argument being the undefined value.

Checking the presence of a mandatory parameter is the "otherwise specified".

[jmdyck]

It's a mandatory parameter (Number.length is 1),

It could be made an 'optional' parameter and Number.length could still be defined to be 1.

and Number() is different than Number(void 0).

Agreed. But that just means that the algorithm has to distinguish between "not present" and *undefined*, which I'm not questioning.

Checking the presence of a mandatory parameter is the "otherwise specified".

Agreed. So it's allowed, but it's still odd. Or maybe I'll downgrade to "unusual". (I.e., I think Number() and String() are the only built-ins where the spec checks for the presence of a 'mandatory' parameter.)

When you say "it's necessary", are you saying that the presence of the "unless otherwise specified" phrase necessitates that there be some place in the spec where it is otherwise specified? Because I'm pretty sure there are several "unless otherwise specified" sentences where it never is otherwise specified.

---

Here's a thought experiment: if the spec explicitly gave the value of the length property for every built-in function, would there be any useful distinction between 'optional' and 'mandatory' arguments? (I had thought that one distinction was that optionals didn't automatically get undefined-for-missing, and so would need an explicit 'present' test, but apparently that's not the case in practice.)

[ljharb]

@jmdyck currently, the only explicit lengths are for where it differs from "the number of non-optional params in the signature", all of which are legacy.

imo every argument should be implicitly undefined when omitted, and may separately be present or absent.

[jmdyck]

@jmdyck currently, the only explicit lengths are for where it differs from "the number of non-optional params in the signature",

(That's not quite true. E.g., the length of the Array constructor is given explicitly as 1, which is the same as its "default argument count". Similarly, the length of the %TypedArray% constructor is explicitly given as 0.)

all of which are legacy.

Well, Number() and String() have both been around since ES1, so surely they qualify as legacy.

imo every argument should be implicitly undefined when omitted, and may separately be present or absent.

Right, so to that extent, you're not drawing a distinction between 'optional' and 'required' parameters.

[jmdyck]

(Similar to previous comment, _value_ is not marked as optional.)

[devsnek]

This left out Array.prototype.flatMap. I can open a PR soonish if no one else does.

[shvaikalesh]

Thank you @devsnek. BigInt.prototype.toString was also left out, and possibly something else. I am making a full sweep now and will open a follow-up PR today.

[devsnek]

@shvaikalesh #1781