Function implicit lengths should not include optional arguments

[ljharb]

http://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects

Every built-in Function object, including constructors, has a length property whose value is an integer. Unless otherwise specified, this value is equal to the largest number of named arguments shown in the subclause headings for the function description, including optional parameters. However, rest parameters shown using the form “...name” are not included in the default argument count.

Most builtin functions that don't mention an explicit length (except for legacy ones like Object and Date) do not include optional parameters in the function's length property. In addition, all of the explicit lengths seem to follow the same guideline.

In addition, function foo(a, b = 3) {}.length gives 1 - default arguments are not included.

The above note should be changed to say: "not including optional parameters.", and if this would meaningfully affect the implicit lengths of any existing functions, then those legacy functions should have explicit lengths added. This change can also remove any explicit lengths that match the changed text.

If everyone is in agreement, I'll be happy to prepare a PR.

[domenic]

It seems better to have explicit lengths everywhere and remove this guidance.

[domenic]

It seems better to have explicit lengths everywhere and remove this guidance.

[ljharb]

I would be 1000% in favor of that! However, it's gotten some pushback previously in the category of "we prefer to avoid redundancy".

[ljharb]

I would be 1000% in favor of that! However, it's gotten some pushback previously in the category of "we prefer to avoid redundancy".

[ljharb]

(It's also worth noting that implementors have often gotten the implicit length wrong, and have even been confused by the current wording, assuming the change I recommend here as fact.)

[ljharb]

(It's also worth noting that implementors have often gotten the implicit length wrong, and have even been confused by the current wording, assuming the change I recommend here as fact.)

[bterlson]

I don't care how we resolve the redundancy really. If people want to make everything explicit I'm fine with that.

The issue here, to be clear, is about what the length of, say, Map is, which has one optional parameter and no explicit length specification. The current language says it should be 1, but it should probably be 0. Edge and Chrome implement 0. I think the current language is just a bug.

[bterlson]

I don't care how we resolve the redundancy really. If people want to make everything explicit I'm fine with that.

The issue here, to be clear, is about what the length of, say, Map is, which has one optional parameter and no explicit length specification. The current language says it should be 1, but it should probably be 0. Edge and Chrome implement 0. I think the current language is just a bug.

[ljharb]

Firefox and Safari also implement 0 for Map.

[ljharb]

Firefox and Safari also implement 0 for Map.

[anba]

I don't mind if the default length computation is switched from "including optional parameters." to "not including optional parameters." in Ch.17. But explicit length definitions everywhere should not be applied for the reasons outlined in #104.

[anba]

I don't mind if the default length computation is switched from "including optional parameters." to "not including optional parameters." in Ch.17. But explicit length definitions everywhere should not be applied for the reasons outlined in #104.

[allenwb]

The value of the length property of Map is specified as 0 in 23.1.2

[allenwb]

The value of the length property of Map is specified as 0 in 23.1.2

[allenwb]

The intent was that new built-ins would follow the same length determination rules as used for ES defined functions, except if the function signature was very similar was very similar to some pre-ES6 built-in that had a different explicitly assigned length value.

For a while in ES6 draft we tried to use ES-style signatures (default values indicating options and rest) for all built-ins but it seemed a poor match to the pseudo-code and there were too many length exceptions for pre-ES6 functions. So we reverted to ES3/5 signature conventions.

Not that even with you give every built-in an explicit length you still probably want to state the default rule somewhere so that future spec. writer have some guidance when assigning lengths for new built-ins.

[allenwb]

The intent was that new built-ins would follow the same length determination rules as used for ES defined functions, except if the function signature was very similar was very similar to some pre-ES6 built-in that had a different explicitly assigned length value.

For a while in ES6 draft we tried to use ES-style signatures (default values indicating options and rest) for all built-ins but it seemed a poor match to the pseudo-code and there were too many length exceptions for pre-ES6 functions. So we reverted to ES3/5 signature conventions.

Not that even with you give every built-in an explicit length you still probably want to state the default rule somewhere so that future spec. writer have some guidance when assigning lengths for new built-ins.

[ljharb]

So it sounds like there is complete consensus that the language in Chapter 17 should change to exclude optional parameters from the length by default - and there is not consensus about whether everything should have an explicit length or not.

If this seems accurate and there are no objections, I'll prepare a PR that updates the language in Chapter 17, and I'll go through every function in the spec in an attempt to minimize explicit length references while matching implementations (the current state).

[ljharb]

So it sounds like there is complete consensus that the language in Chapter 17 should change to exclude optional parameters from the length by default - and there is not consensus about whether everything should have an explicit length or not.

If this seems accurate and there are no objections, I'll prepare a PR that updates the language in Chapter 17, and I'll go through every function in the spec in an attempt to minimize explicit length references while matching implementations (the current state).

[bterlson]

@ljharb I would accept such a PR :) Depending on how much normatively changes (I suspect not much) we may or may not want to get committee feedback before pulling it in. But I suspect the normative changes will be minimal.

[bterlson]

@ljharb I would accept such a PR :) Depending on how much normatively changes (I suspect not much) we may or may not want to get committee feedback before pulling it in. But I suspect the normative changes will be minimal.