http://krijnhoetmer.nl/irc-logs/whatwg/20131016#l-503 for context

I assumed the idea would be to add a new "required" modifier, since changing every non-optional argument in this way doesn't seem realistic (eg. making alert() throw instead of showing "undefined").  It'd be nice if that's possible, though.

alert() is optional and defaults to "".

This seems good to me.

FYI, I was thrown off a bit by the IRC conversation.  The discussion started with "you can't make CSS.escape throw for missing arguments, that's not how JavaScript works" (http://krijnhoetmer.nl/irc-logs/whatwg/20131016#l-409), which ended in "we can do this as long as we make sure it throws if undefined is passed in too".  Actually, tons of functions throw for missing arguments already (WebIDL 4.5.1.1), and passing undefined isn't the same as not passing an argument, so the discussion didn't make any sense.

This ticket is different: it's saying to change all of those existing required arguments to throw if undefined is passed in.  That seems trivially better (passing undefined to xhr.open() and opening "undefined" is never what you meant to do), but I'm not sure it's worth the churn if there's already interop.

(In reply to Glenn Maynard from comment #5)

> ... I'm not sure it's worth the churn if there's
> already interop.

The point is to align with ES optional parameters

http://people.mozilla.org/~jorendorff/es6-draft.html#sec-destructuring-binding-patterns-runtime-semantics-indexedbindinginitialisation

Given that the platform already seems to have interop, shouldn't ES optional parameters be the one doing the aligning?

(In reply to Glenn Maynard from comment #7)
> Given that the platform already seems to have interop, shouldn't ES optional
> parameters be the one doing the aligning?

We talked about this in length several times over the last year. Using arguments.length as the base for optional parameters has too many issues. See es-discuss and notes from multiple f2f tc39 meetings.

Since it's what the platform already does, and it seems to have interop across all major browsers, it's probably just too late.  Maybe it's possible to make this happen, but this is a change that would affect hundreds of functions across every API on the platform.  I'd check for buy-in from all major vendors before making such a huge change, or we'll just lose the interop we have now.

(In reply to Glenn Maynard from comment #9)
> Since it's what the platform already does, and it seems to have interop
> across all major browsers, it's probably just too late.  Maybe it's possible
> to make this happen, but this is a change that would affect hundreds of
> functions across every API on the platform.  I'd check for buy-in from all
> major vendors before making such a huge change, or we'll just lose the
> interop we have now.

Consensus was reached between representatives of all major implementors (Apple, Google, Microsoft and Mozilla all present): https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-07/july-24.md#consensusresolution-2

> Consensus was reached between representatives of all major implementors

With all due respect, the people representing SpiderMonkey there have nothing to do with the methods this bug is talking about changing.  In particular, they do not have any idea of what the compatibility constraints, if any, are.  So their consensus on the ES behavior doesn't mean much for the DOM, unfortunately.

As far as the DOM goes, we've so far failed to make the change of treating undefined as "not passed, use default value" for optional arguments: it's run into compat issues in at least two cases.  We may be able to work around those on the DOM side by modifying the IDL to not use optional arguments (for one we can; for the other it's not even clear yet which API is involved, so it's hard to tell), but there might be more.  It'll be a long slog, with broken websites galore, before the fallout from that change settles, I suspect.

For the case in this bug, it's hard to say anything about compat impact until someone tries it....

So I've thought about this some more.

This bug's proposal (comment 0) comes down to making a whole bunch of methods that currently do not throw in certain cases start throwing in those cases.

Specifically, converting undefined to non-nullable interface arguments threw anyway.  But conversion to nullable interface arguments used to produce null and would now throw, and conversion to primitives used to produce 0/false/"undefined" (depending on the kind of primitive) and would now throw.

I strongly suspect that such a change is not web-compatible wholesale, which means that if we make it we will need to explicitly flag various APIs that are exceptions to the general rule for web compat purposes.  Coming up with such a list of APIs would be at best time-consuming and error-prone (in the sense of shipping browsers that break websites and finding out about that the hard way).

I do not expect Gecko to ship such a change before other UAs have done so and have submitted feedback on which APIs they had to munge for compat reasons (which is not a given, since other UAs seem to have a history of not submitting such feedback at all).  I strongly doubt any other UA vendors are any more willing than I am to stick their hands into this meat-grinder, but if they are they should of course speak up!

Another, perhaps less breakage-prone, way to get to the world proposed in comment 0 is to simply drop all arguments.length checks from WebIDL altogether and just blindly coerce things as needed.  So omitting a Node argument would still throw, but omitting a "Node?" argument would in fact act just like passing explicit undefined would.  A bunch of stuff like calling setAttribute() with only one argument (or no arguments, for that matter) which is currently specified to throw would stop throwing, which is a safer change to make than the reverse, albeit one that leads to less-debuggable code.  In this world, I'm not quite sure how overload resolution will work, but if this is the direction we want to go we can try to figure that out.  In some ways, overloaded methods that cannot be reexpressed in terms of unions are already so whack that it doesn't matter _that_ much how we resolve them.  :(

I should note that the "less breakage-prone" world is where WebKit and Blink already live, as far as I can tell.  Try http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2580 in Chrome or Safari.

One more note: the change I describe sounds to me like putting theoretical purity ahead of web developers, since I suspect web developers would prefer a clear indication that a call like document.body.setAttribute() (with no arguments) is incorrect instead of it silently doing something bogus...  But that wouldn't be the first time, I guess; as far as I can tell we have a different priority of constituencies (though not spelled out) in TC39 than the WHATWG and HTMLWG generally seem to.

FWIW I would object to the change in Comment 12 for exactly the reason given in Comment 13; it makes the API more developer hostile but has few practical advantages. I also agree that the change suggested in Comment 0 is dangerous, but since there are people who seem to think that this consistency is important I hope they will do the work to discover the compatibility constraints.

>  since I suspect web developers would prefer a clear indication that a call like document.body.setAttribute() (with no arguments) is incorrect instead of it silently doing something bogus...

I don't think this is true, given the wide acceptance and prevalence of web developer-created libraries that do not do argument validation of this sort. (For example, jQuery.) Argument validation exceptions are not idiomatic to or expected by JavaScript code, generally. The only general case where I can recall developers writing them is for ensuring that properties of a configuration file necessary for app startup are present.

That said, even though I think it is a mistake to have these kind of argument validation exceptions, I can see that there are a number of people writing standards who are fond of them, so in the end it's unlikely that developers' desires are really what's going to decide the outcome here. With that in mind I think the original post describes the best way to express required arguments: if it's `undefined`, throw your `TypeError`.

Finally, I'd like to emphasize that `arguments`, and thus `arguments.length`, won't even be available inside any of ES6's new function forms, e.g. arrow functions, or any functions that use default arguments, rest parameters, or destructuring in their declaration. TC39 is trying as hard as possible to kill `arguments`.

(In reply to Domenic Denicola from comment #15)
> >  since I suspect web developers would prefer a clear indication that a call like document.body.setAttribute() (with no arguments) is incorrect instead of it silently doing something bogus...
> 
> I don't think this is true, given the wide acceptance and prevalence of web
> developer-created libraries that do not do argument validation of this sort.
> (For example, jQuery.) Argument validation exceptions are not idiomatic to
> or expected by JavaScript code, generally.

Of course we want to be told when we're doing something that is blatantly incorrect.  Libraries don't do it because it's cumbersome to do in JavaScript, but that's a bug, not a feature.

I believe the rules in comment #0 are a bit too simplistic. For example passing undefined to a required boolean parameter needs to coerce it to false.

I believe the following rules would work.

1. Treat all nullable and boolean trailing parameters as optional. If there are optional parameters after a required parameter treat it as if it was optional.

  void foo(boolean b, optional T t)

would be treated as 

 void foo(optional boolean b = false, optional T t)

2. Treat all trailing nullable required parameters as optional, default to null.
3. For nullable required parameters treat undefined as null.
4. For boolean required parameters treat undefined as false.
5. For other required parameters, undefined and missing is an error.
6. For other optional parameters, undefined triggers the default

I think this can be simplified further but the main point is that we should be able to pass undefined to nullable and boolean parameters.

(In reply to Boris Zbarsky from comment #11)
> > Consensus was reached between representatives of all major implementors
> 
> With all due respect, the people representing SpiderMonkey there have
> nothing to do with the methods this bug is talking about changing.  In
> particular, they do not have any idea of what the compatibility constraints,
> if any, are.  So their consensus on the ES behavior doesn't mean much for
> the DOM, unfortunately.
> 

I don't think this is a fair statement WRT compatibility constrains. TC39 imposes severe compatibility constraints upon ourselves.  Our aspirational goal is to never break any existing JS code.  We would never change the language or the API of any ES built-in function in a way that would invalidate existing uses of the function. When we find this goal impossible to achieve  we are very careful to determine that any code that is broken is a extreme outlier.

From a TC39 perspective, we would say that, of course, you cannot invalidate any existing DOM API.

In Comment #12 you said,
>This bug's proposal (comment 0) comes down to making a whole bunch of methods
>that currently do not throw in certain cases start throwing in those cases.

If that's correct, it's absurd. There is no way that could actually happen to the web platform. 

There is nothing in ES6 that forces any changes to DOM APIs.   However, it will be good for the long term health of the platform, if DOM APIs began to look more like idiomatic JS APIs. The place to start is with new APIs.  My sense is that much of the difficulty you are encountering is that you are trying to apply a common set of conventions to both new APIs and your legacy APIs and this just doesn't work well because many of the legacy APIs do not follow idiomatic JS conventions.

What we do in TC39, in similar cases, is to simply bite the bullet and  describe the legacy API accurately but without using ES6 conveniences (such as default parameter values) that are inconsistent with the legacy. When all else fails we simply describe then as if the parameter signature was (...args) and provide an algorithic definition of the parameter processing.

Allen

> With that in mind I think the original post describes the best way to express
> required arguments: if it's `undefined`, throw your `TypeError`.

My point is that I'll bet you $500 that doing this for setAttribute is not web-compatible.  Certainly not for the second argument.  I would be all in favor of doing this if it were not for this minor little detail.  Certainly if we were designing this as a green-field system we'd want to do that.

On the other hand, throwing if the argument is omitted altogether _is_ web-compatible.

> I believe the following rules would work.

Erik, I don't think these rules cover the setAttribute case at all.  Do you think you can compatibly change that case to throw if explicit undefined is passed?  If not, you need different rules.

> From a TC39 perspective, we would say that, of course, you cannot invalidate
> any existing DOM API.

Clearly at least Domenic disagrees...  but yes, that would be the sane approach to API design.

> The place to start is with new APIs.

That's not the proposal in this bug, sadly.  But yes, that would be much more palatable to me as an implementor.

> Clearly at least Domenic disagrees...  but yes, that would be the sane approach to API design.

I'm sorry if I've given any impression to the contrary. I thought we were discussing WebIDL rules, not what specific APIs should do. Specific APIs are constrained by web-compat; nobody is arguing that.

That said, we can still make fixes in the name of increased consistency where possible, and I'd argue that if setAttribute doesn't throw for undefined, it should not throw for missing argument. From what I can tell you believe this is still web compatible?

If the goal is "treat passing undefined the same as not passing the argument at all, even for non-optional arguments", then we actually have two options:

For a function like "void func(double arg)"

A) Make both func() and func(undefined) throw TypeError.
B) Make both func() and func(undefined) be equivalent to
   func(ToNumber(undefined)), i.e. equivalent to func(NaN).

So far we've mostly debated A, which doesn't seem very web compatible.

We certainly could do A for any new functions added to the platform, however that would create inconsistency between old and new functions which is unfortunate.

B is likely much more web compatible, and could probably be done for both old and new APIs. Not throwing also feels a lot more "javascripty", but that's obviously a matter of opinion.

I even *think* WebKit (and thus Blink) has done B for a long time.

(In reply to Jonas Sicking from comment #21)
> For a function like "void func(double arg)"
> 
> A) Make both func() and func(undefined) throw TypeError.
> B) Make both func() and func(undefined) be equivalent to
>    func(ToNumber(undefined)), i.e. equivalent to func(NaN).
> 
> I even *think* WebKit (and thus Blink) has done B for a long time.

Assuming func is not overloaded, then in Blink (and WebKit last I knew) func() throws TypeError but func(undefined) coerces.

(In reply to Jonas Sicking from comment #21)
> If the goal is "treat passing undefined the same as not passing the argument
> at all, even for non-optional arguments", then we actually have two options:
> 
> For a function like "void func(double arg)"
> 
> A) Make both func() and func(undefined) throw TypeError.
> B) Make both func() and func(undefined) be equivalent to
>    func(ToNumber(undefined)), i.e. equivalent to func(NaN).
> 
> So far we've mostly debated A, which doesn't seem very web compatible.
> 
> We certainly could do A for any new functions added to the platform, however
> that would create inconsistency between old and new functions which is
> unfortunate.
> 
> B is likely much more web compatible, and could probably be done for both
> old and new APIs. Not throwing also feels a lot more "javascripty", but
> that's obviously a matter of opinion.
> 
and B is exactly how a JS function defined as
   function func(aNumber) { return +aNumber}

would behave if called either as func() or func(undefined)

It what a JS programmer expects, if leave out a argument that is used as a  number (or pass undefined) it will be treated as if it was NaN.

I am extremely skeptical of any claim that, given a function domFoo that takes a single non-optional, argument, js programmers benefit more from consistency between domFoo() and domFoo(undefined) than they do from throwing when the argument is missing. It seems far more likely to me that users missing non-optional arguments have made a mistake than that they are deliberately trying to invoke the effect of passing undefined, not least because the effect of passing undefined itself is often rather useless, and leads to a bad result (NaN, "undefined", null, etc.) which then propagates through the rest of the code making it extremely difficult to locate the original source of the bug.

Unless anyone has any concrete evidence that my suppositions above are incorrect, I oppose removing throwing behavior from legacy APIs and suggest throwing in both cases in future APIs.

It's certainly not what a JS programmer wants.  Having "Math.ceil()" return NaN instead of throwing an exception is useless, and does nothing but make development more difficult.

It may well not be web-compatible to throw in many cases (and that's ultimately what matters), but it's definitely better.  When it's this certain the programmer has made a mistake, tell them.

Though the same could probably be said for calling func(undefined). That seems likely to have happen due to code like

function doStuff(a) {
  ...
  func(a);
  ...
}
doStuff();

or

function doStuff(a) {
  ...
  func(a.value);
  ...
}
doStuff({ x: 12, y: 13 });


I can't say I have a strong opinion here. I still dislike the idea of having a split between old and new functions, but maybe it's better than the alternative.

One possible out would be to add warnings whenever undefined is passed to a required argument. And then slowly try to migrate old APIs to the new convention. But it sounds like bz's appetite is pretty low for that which I can understand given the amount of web-breaking experiments he's been through lately.

(In reply to Domenic Denicola from comment #20)
> I thought we were discussing WebIDL rules, not what specific APIs should do.

If you change the meaning of a given string of WebIDL, that immediately changes all APIs that use that string of WebIDL.

The only options to not do that are to either make the new behavior uses a new syntax not used in current APIs or to go through all existing APIs and change them (or some subset of them, perhaps) to use some new syntax that opts out of the new behavior.

> That said, we can still make fixes in the name of increased consistency
> where possible, and I'd argue that if setAttribute doesn't throw for
> undefined, it should not throw for missing argument. From what I can tell
> you believe this is still web compatible?

It's web compatible.  I just think it's developer-hostile.

(In reply to Joshua Bell from comment #22)
> Assuming func is not overloaded, then in Blink (and WebKit last I knew)
> func() throws TypeError but func(undefined) coerces.

That's not the case in many cases.  See the simple testcase linked at the end of comment 12.

On the other hand, in Chrome document.querySelector() (with no arguments) does throw due to what looks like an arguments.length check.  But document.getElementById() (again, with no arguments) silently returns null.  So I can't tell when WebKit/Blink treat no argument as undefined and when they throw an exception.  Certainly it seems wholly uncorrelated with what any spec says right now.

(In reply to Jonas Sicking from comment #26)
> And then slowly try to migrate old APIs to the new convention.

In the long run that gives us a mix of APIs using the two conventions, I would expect...  Happy to see someone prove me wrong.

(In reply to Boris Zbarsky from comment #27)
...
> 
> (In reply to Jonas Sicking from comment #26)
> > And then slowly try to migrate old APIs to the new convention.
> 
> In the long run that gives us a mix of APIs using the two conventions, I
> would expect...  Happy to see someone prove me wrong.

No you're right.  But mixed conventions is already the reality for web developers who work a platform that includes the DOM APIs, the built-in JS APIs, and third party libraries that typically for the JS conventions. 

It will be better if new DOM APIs to follow the JS conventions, like everybody else.

If we want ES and DOM APIs to align, and the DOM APIs have clearly more useful behaviour, perhaps the ES APIs should change?

(In reply to Ms2ger from comment #29)
> If we want ES and DOM APIs to align, and the DOM APIs have clearly more
> useful behaviour, perhaps the ES APIs should change?

There is one big difference between DOM APIs and JS. In JS you need to write functions that has optional parameters and calls other functions with optional parameters. In DOM you only need to call functions.

If you use arguments.length for these you have to do a lot of boiler plate code to cover all the options.

function g(x = undefined, y = undefined, z = undefined) {}

function f(x = undefined, y = undefined, z = undefined) {
  // do something
  switch (arguments.length) {
    case 0:
      return g();
    case 1:
      return g(x);
    case 2:
      return g(x, y);
    default:
      return g(x, y, z);
  }
}

But using the semantics in ES6

function f(x = undefined, y = undefined, z = undefined) {
  // do something
  return g(x, y, z);
}

Also, whether WebIDL has a more useful behavior is debatable. I haven't seen many (any?) JS libraries follow WebIDL.

(In reply to Erik Arvidsson from comment #30)
> Also, whether WebIDL has a more useful behavior is debatable. I haven't seen
> many (any?) JS libraries follow WebIDL.

That data would also fit the hypothesis that argument validation is too hard to do in JS and people are lazy so don't bother. Given that it is easy to make a case that throwing is preferable for API users but no one has even attempted to make a case, other than consistency, why not throwing might be preferable, I think my alternative hypothesis is significantly more likely.

(In reply to James Graham from comment #31)
> (In reply to Erik Arvidsson from comment #30)
> > Also, whether WebIDL has a more useful behavior is debatable. I haven't seen
> > many (any?) JS libraries follow WebIDL.
> 
> That data would also fit the hypothesis that argument validation is too hard
> to do in JS and people are lazy so don't bother. Given that it is easy to
> make a case that throwing is preferable for API users but no one has even
> attempted to make a case, other than consistency, why not throwing might be
> preferable, I think my alternative hypothesis is significantly more likely.

Step right up.  I've explained this many times to many people but will happily do it again.

Excess parameter validation is a well known anti-pattern among experienced dynamic language programmers. It results in code bloat and sometimes performance issues.

The code bloat is the occurrence of explicit "type" guards that occur over and over again in every functions. The majority of these are redundant and unnecessary because, if they really matter for safety (memory or operational), then the language guarantees the downstream primitive use of the value will perform the necessary safety checks.  

The performance issue, is that all of these checks are completely unnecessary, in a well tested  program. In such a program all values will validate correct, so they add nothing to the actual computational purpose of a function. Put a lot of these in a hot loop and you have a perf problem.

So when should a function (coded in a dynamic language) perform explicit parameter validation?  Only when the validation is necessary for maintaining essential invariants that the function is directly responsible for maintaining and even then only as a guard on the actual operations that are sensitive to the value.  Also, never explicitly validate something that is going to be validate by a primitive operation.

If you are just passing a parameter value on to another function, don't validate. The function you are calling should perform the validation if it is necessary for it to maintain its invariants. But more like than not, it also will just pass the value on and won't need to validate either.

So, aren't APIs special in ways that require that everything must be validate?  Sometimes, but certainly not always. (See http://www.wirfs-brock.com/allen/posts/379 for a deeper exploration of this question).  Many web platform APIs are just routine functions that are not special in any way and don't require any dynamic parameter validation.

Verifying the number of parameters is not "excess validation".  Verifying the number of parameters is a useful and well-understood part of modern dynamic languages.  See Python for a good example.

We can't get this everywhere in JavaScript due to heavy legacy constraints, but that doesn't mean we shouldn't have it at all.

(In reply to Glenn Maynard from comment #33)
> Verifying the number of parameters is not "excess validation".  Verifying
> the number of parameters is a useful and well-understood part of modern
> dynamic languages.  See Python for a good example.

If a specific number of arguments is necessary for the given function to maintain its invariants, then the function should be defined with named formal parameters.


> 
> We can't get this everywhere in JavaScript due to heavy legacy constraints,
> but that doesn't mean we shouldn't have it at all.

There are no constraints described in your response.

(In reply to Rick Waldron from comment #34)
> (In reply to Glenn Maynard from comment #33)
> > Verifying the number of parameters is not "excess validation".  Verifying
> > the number of parameters is a useful and well-understood part of modern
> > dynamic languages.  See Python for a good example.
> 
> If a specific number of arguments is necessary for the given function to
> maintain its invariants, then the function should be defined with named
> formal parameters.

I can't tell what your reply has to do with what I wrote.  Named formal parameters are what we're discussing.  Please clarify.

> > We can't get this everywhere in JavaScript due to heavy legacy constraints,
> > but that doesn't mean we shouldn't have it at all.
> 
> There are no constraints described in your response.

There weren't intended to be.  Everybody reading this thread already knows that web compatibility is the legacy that constrains changing web APIs.

(In reply to Glenn Maynard from comment #35)
> (In reply to Rick Waldron from comment #34)
> > (In reply to Glenn Maynard from comment #33)
> > > Verifying the number of parameters is not "excess validation".  Verifying
> > > the number of parameters is a useful and well-understood part of modern
> > > dynamic languages.  See Python for a good example.
> > 
> > If a specific number of arguments is necessary for the given function to
> > maintain its invariants, then the function should be defined with named
> > formal parameters.
> 
> I can't tell what your reply has to do with what I wrote.  Named formal
> parameters are what we're discussing.  Please clarify.

You said: 

> Verifying the number of parameters is not "excess validation".  Verifying
> the number of parameters is a useful and well-understood part of modern
> dynamic languages.  See Python for a good example.

Specifically: 

> Verifying the number of parameters

Which I assumed (maybe incorrectly) that you meant eg. defining conditional semantics of a function based on arguments.length. If that's what you meant, then I'm arguing this approach is brittle and error prone, versus defining conditional semantics by naming your parameters and observing their argument value.

Rick, this bug is all about named formal parameters.  Checking their argument value for undefined and throwing if that's what was passed is almost not web-compatible in general.  That's what all the discussion is about!

I am pretty sure this is fixed for a couple years now, but someone should please reopen if I misunderstood.