Discuss
  • Using destructuring for function arguments

Using destructuring for function arguments

# Nicholas C. Zakas (10 years ago)

I've been playing around with using destructuring as function arguments and have come across some odd behaviors that I'm not sure are intentional (or perhaps, not to spec). For context, consider the following function:

function setCookie(name, value, { secure, path, domain, expires }) {
     console.log(secure);
     // ...
}

// called as
setCookie("type", "js", {
     secure: true
});

What happens here:

  • secure === true
  • path === undefined
  • domain === undefined
  • expires === undefined

I'd say all of that behavior is as expected. However, if I omit the third argument completely, things get a bit strange:

setCookie("type", "js");   // throws error at console.log

What happens here is that none of secure, path, domain, expires are defined. I can use typeof on them to protect against this, but then I end up with some lousy looking code:

function setCookie(name, value, { secure, path, domain, expires }) {

     if (typeof secure !== "undefined") {
         // use it
     }

     if (typeof path !== "undefined") {
         // use it
     }

     if (typeof domain !== "undefined") {
         // use it
     }

     if (typeof expires !== "undefined") {
         // use it
     }

     // ...
}

My first thought was that this behavior made sense, since no destructuring can happen on undefined. However, the workaround for dealing with that behavior seems a bit heavy-handed.

I thought perhaps I could assign a default value, and that would solve the problem:

function setCookie(name, value, { secure, path, domain, expires } = {}) {
     console.log(secure);
     // ...
}

Unfortunately, that resulted in a syntax error in Firefox. Traceur seems to have no problem with it.

So I really have two questions:

  1. Who is right about assigning a default value to a destructured parameter, Firefox or Traceur?
  2. Is the behavior of not having any bindings for destructured parameter properties correct? And if so, is it desirable?

Thanks.

# Matthew Robb (10 years ago)

Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned.

# Dmitry Soshnikov (10 years ago)

On Sat, May 31, 2014 at 11:59 AM, Nicholas C. Zakas < standards at nczconsulting.com> wrote:

I've been playing around with using destructuring as function arguments and have come across some odd behaviors that I'm not sure are intentional (or perhaps, not to spec). For context, consider the following function:

function setCookie(name, value, { secure, path, domain, expires }) {
    console.log(secure);
    // ...
}

// called as
setCookie("type", "js", {
    secure: true
});

What happens here:

  • secure === true
  • path === undefined
  • domain === undefined
  • expires === undefined

I'd say all of that behavior is as expected. However, if I omit the third argument completely, things get a bit strange:

setCookie("type", "js");   // throws error at console.log

What happens here is that none of secure, path, domain, expires are defined. I can use typeof on them to protect against this, but then I end up with some lousy looking code:

function setCookie(name, value, { secure, path, domain, expires }) {

    if (typeof secure !== "undefined") {
        // use it
    }

    if (typeof path !== "undefined") {
        // use it
    }

    if (typeof domain !== "undefined") {
        // use it
    }

    if (typeof expires !== "undefined") {
        // use it
    }

    // ...
}

Strange, it seems should fail at trying to start destructuring process: when ToObject coercion fails with the undefined value set to the value of the parameter.

My first thought was that this behavior made sense, since no destructuring can happen on undefined. However, the workaround for dealing with that behavior seems a bit heavy-handed.

I thought perhaps I could assign a default value, and that would solve the problem:

function setCookie(name, value, { secure, path, domain, expires } = {}) {
    console.log(secure);
    // ...
}

Unfortunately, that resulted in a syntax error in Firefox. Traceur seems to have no problem with it.

So I really have two questions:

  1. Who is right about assigning a default value to a destructured parameter, Firefox or Traceur?

Well, the the FormalParameter is the BindingElement, and the later may be the BindingPattern Initializer, where the Initializer is your default value. From which chain Traceur is correct.

  1. Is the behavior of not having any bindings for destructured parameter properties correct? And if so, is it desirable?

Where do you test this? It seems it should fail at destructuring, and not set any binding pattern properties in this case.

I.e.

setCookie('type', 'js'); // throws right away, since no ToObject coercion
is made
setCookie('type', 'js', {}); // sets all binding props to undefined

With the default value of the pattern, the first call sets all binding props to undefined as well.

Dmitry

# Brendan Eich (10 years ago)

Nicholas C. Zakas wrote:

function setCookie(name, value, { secure, path, domain, expires } = {}) {
    console.log(secure);
    // ...
}

Unfortunately, that resulted in a syntax error in Firefox.

Could you please file a bug against SpiderMonkey? Thanks,

# Brendan Eich (10 years ago)

Matthew Robb wrote:

Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned.

Right, and they are in scope no matter what.

Seems to me that an implementation bug (can't have parameter default value for destructuring formal) is the only problem brought to light in this thread. Anyone see anything else amiss?

# Allen Wirfs-Brock (10 years ago)

On May 31, 2014, at 8:59 PM, Nicholas C. Zakas <standards at nczconsulting.com> wrote:

I've been playing around with using destructuring as function arguments and have come across some odd behaviors that I'm not sure are intentional (or perhaps, not to spec).

Argument binding initialization takes place as part of people.mozilla.org/~jorendorff/es6-draft.html#sec-functiondeclarationinstantiation The actual initialization takes place in steps 24-25, essentially treating the entire parameter list as an array-like restructuring

Note that there has been significant tweaks to this section in each of the 3 latest spec. drafts. You favorite implementation may not match the current spec. text.

For context, consider the following function:

function setCookie(name, value, { secure, path, domain, expires }) {
   console.log(secure);
   // ...
}

// called as
setCookie("type", "js", {
   secure: true
});

What happens here:

  • secure === true
  • path === undefined
  • domain === undefined
  • expires === undefined

I'd say all of that behavior is as expected. However, if I omit the third argument completely, things get a bit strange:

setCookie("type", "js");   // throws error at console.log

correct, this should throw a TypeError exception because desctructuring patterns (in any context) require an object value to restructure. Since you did not pass a third argument there is no object to restructure into {secure, path, domain, expires}

What happens here is that none of secure, path, domain, expires are defined. I can use typeof on them to protect against this, but then I end up with some lousy looking code:

not really, the thrown exception while processing the arguments should terminate the function and you should never start executing the function body

function setCookie(name, value, { secure, path, domain, expires }) {

   if (typeof secure !== "undefined") {
       // use it
   }

   if (typeof path !== "undefined") {
       // use it
   }

   if (typeof domain !== "undefined") {
       // use it
   }

   if (typeof expires !== "undefined") {
       // use it
   }

   // ...
}

My first thought was that this behavior made sense, since no destructuring can happen on undefined. However, the workaround for dealing with that behavior seems a bit heavy-handed.

I thought perhaps I could assign a default value, and that would solve the problem:

function setCookie(name, value, { secure, path, domain, expires } = {}) {
   console.log(secure);
   // …

yes the above is exactly what you are expected to do. Or you could include some defaults in the default object:

{secure, path, domain, expires } = {secure: false}

}

Unfortunately, that resulted in a syntax error in Firefox. Traceur seems to have no problem with it.

that sounds like a Firefox bug

So I really have two questions:

  1. Who is right about assigning a default value to a destructured parameter, Firefox or Traceur?

Traceur

  1. Is the behavior of not having any bindings for destructured parameter properties correct? And if so, is it desirable?

no, it is supposed to throw as discussed above.

# Jason Orendorff (10 years ago)

On Sat, May 31, 2014 at 1:59 PM, Nicholas C. Zakas <standards at nczconsulting.com> wrote:

  1. Who is right about assigning a default value to a destructured parameter, Firefox or Traceur?

Traceur is right.

  1. Is the behavior of not having any bindings for destructured parameter properties correct? And if so, is it desirable?

I think you're mistaken about this. What happens is that

function setCookie(name, value, { secure, path, domain, expires }) {
    console.log(secure);
    // ...
}

behaves like

function setCookie(name, value, options) {
    var { secure, path, domain, expires } = options;
    console.log(secure);
    // ...
}

and the error is in trying to unpack options, which is undefined, not in later trying to use the variables.

# Kevin Smith (10 years ago)

In addition to what Allen said, you could also do something like this:

function setCookie(name, value, { secure, path, domain, expires } = cookieDefaults) { }

where cookieDefaults is defined elsewhere.

Or you could do something like:

function setCookie(name, value, { secure = false, path = ".", domain = "", expires = now() } = {}) { }

where you are specifying default initializers within the destructuring pattern.

# Kevin Smith (10 years ago)

Or, for more readable code:

function setCookie(name, value, options = {}) {

    let {

        secure = false,
        path = "",
        domain = "",
        expires = whenever()

    } = options;

    // Do stuff

}

Kevin

​

# Dmitry Soshnikov (10 years ago)

On Sat, May 31, 2014 at 1:41 PM, Brendan Eich <brendan at mozilla.org> wrote:

Matthew Robb wrote:

Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned.

Right, and they are in scope no matter what.

Seems to me that an implementation bug (can't have parameter default value for destructuring formal) is the only problem brought to light in this thread. Anyone see anything else amiss?

No, seems it's the only problem. Also, just to add: esprima parser also has this bug yet (can't have param default value with patterns).

Dmitry

# Brendan Eich (10 years ago)

Dmitry Soshnikov wrote:

No, seems it's the only problem. Also, just to add: esprima parser also has this bug yet (can't have param default value with patterns).

Nicholas kindly filed

bugzilla.mozilla.org/show_bug.cgi?id=1018628

to track the SpiderMonkey bug. If you file an Esprima one, could you cite it to the list? Thanks,

# Nicholas C. Zakas (10 years ago)

On 5/31/2014 1:54 PM, Allen Wirfs-Brock wrote:

What happens here is that none of secure, path, domain, expires are defined. I can use typeof on them to protect against this, but then I end up with some lousy looking code:

not really, the thrown exception while processing the arguments should terminate the function and you should never start executing the function body

This sounds like there's a second error in the Firefox implementation. If an error should be thrown when the destructured argument is omitted, then Firefox is incorrectly continuing to execute the function body.

Am I reading this correctly?