ES6 in Chromium proposal: Allow default function parameters

[dpapad]

Hi Chromium devs,

If you don't read/review/author JS code in Chromium you can stop reading now.

Proposing to move Default function parameters to the "allowed features" section of the ES6 style guide.

Style guide section:

https://chromium.googlesource.com/chromium/src/+/master/docs/es6_chromium.md#default-function-parameters

Example

Before

function foo(opt_a) {
  let a = opt_a || 'default_value';
  console.log(a);
}

After

function foo(a = 'default value') {
 console.log(a);
}

Notable difference

ES6 default parameter is triggered ONLY if the parameter is passed as undefined. Passing null, or any other false-y value will not trigger the default parameter. This is explained better here.

In other words, the ES5 equivalent of how ES6 default parameters work, is

function foo(opt_a) {
  let a = opt_a === undefined ? 'default_value' : opt_a;
  console.log(a);

which results in

foo();          // prints 'default_value'
foo(undefined); // prints 'default_value'
foo(0);         // prints 0
foo('');        // prints ''
foo(null);      // prints null
foo('bar');     // prints 'bar'

But in most cases where default parameters are implemented in existing code, the pattern shown in the 1st example of this email is used, which is lenient with false-y values, and therefore it would return

foo();          // prints 'default_value'
foo(undefined); // prints 'default_value'
foo(0);         // prints 'default_value'
foo('');        // prints 'default_value'
foo(null);      // prints 'default_value'
foo('bar');     // prints 'bar'

See this example CL where migrating to ES6 default parameters, required changing "null" to "undefined" in functions that expect multiple optional parameters, as a way to trigger the ES6 default parameter.

Benefit

More concise code, and consistent default parameter behavior. Currently each author re-implements default parameters in each function, with slightly different behavior. This is also error prone. Consider the following example:

/** @param {number=} opt_a */
function foo(opt_a) {
  let a = opt_a || -1;
  console.log(a);
}

// Unclear if this is a bug or intended. Should zero be overriden,
// or was it an oversight about how false-y values work?
foo(0); // prints -1

Compatibility:

Looks good, except for iOS9 which does not seem to support it. We would need to restrict usage from any code that uses iOS9 (potentially with a PRESUBMIT warning, similar to what we've done with other ES6 features).

https://kangax.github.io/compat-table/es6/#test-default_function_parameters

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters

Interested hearing your thoughts.

Thank you,

Demetrios 

[Hector Carmona]

LGTM. Being able to avoid accidental bugs caused by falseyness is good.

--

Hector Carmona |

Software Engineer |

hcar...@google.com

[Mike Frysinger]

i like default params, and the Google JS guide also permits them

as part of the move, can we also include/document the ban on "opt_" prefixes when using default params ?  it's also what the Google JS guide says, and it's what closure compiler does.

specifically, these are OK:

  function foo(opt_a) {

  function foo(a = 'foo') {

but this should be disallowed:

  function foo(opt_a = 'foo') {

-mike

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/669587d1-ebfb-4c7d-9c3b-004ab6a63e60%40chromium.org.

[dpapad]

Our Chromium JS styleguide inherits from the Google one, see note here. So I don't think we need to do anything special to document/include the "opt_" prefix ban. We could potentially enforce an ESLint check for this, if there is an ESLint rule that could be leveraged.

[PhistucK]

Note that the fact that it only applies to undefined/non-passed parameters is tricky. Even the V8 team (or whoever writes their blog posts) got it wrong when they presented an example that included null as a case where the default parameter value would be used instead. :(

I know you mentioned that, but it cannot be stressed enough, because it makes it not only confusing, but much less efficient in a lot of cases (false-y-ness can be good just as much as it can be bad).

(Full disclosure - I started an deserted WICG thread about this some time ago)

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/c86df772-95a5-487c-880b-09258b591428%40chromium.org.