Optional named parameters

💡 Ideas
21

You already have to parse a defintion of a function first in many cases. For example:

// browser: don't know this one
helloMyFirend('Con Artist-Six');

// browser: oh, yeah that hoisting thingy, must remeber on next pass
function helloMyFirend(user, messageTpl = (u)=>`Hi, ${u}`) {
	console.log(messageTpl(user))
}

As you probably know, this already works in all browsers (including IE11). So browsers already need to effectively perform a double pass on each script. Shouldn't be that much different.

In moder code where you use const/let the defintion will always have to be above the call. So one pass.

22

You lost me. The main question is how this feature would transpile. The solution I suggested there would work as a transformation. It shouldn't have any special interaction with hoisting I don't think...

23

Yes, your transpilation looks fine to me too. I guess I misunderstood what you meant by "locality of transpilation" and wanted to address it too. I thought you meant that JS transpilation shouldn't require circling back to the function definition, but if you think that’s resolved already, then OK. :)

24

What I meant is that there can't be "spooky action at a distance". Basically the only thing that should be able to change the transpiled output of a given file is the input file.

Otherwise when I make a change to the code in file a.js it sometimes both the contents of a.built.js and b.built.js need to be changed. It's much, much easier to write performant tools if b.built.js only ever needs to change when b.js has changed. (This is assuming that code in b.js calls into a function with named arguments defined in a.js)

25

So long as each output depends only on the input you can just spin up a bunch of threads and you'll be done mighty quick. Babel got that right early on by supporting all of TS except for its const enums because the const enum language feature broke the 1:1 rule, causing action at a distance and forcing single-threading. So many people switched to using Babel to transpile TS to JS that I would only label that TS feature as having "partial support" if I were making a compatibility matrix comparing feature support in all the places TS code is written. Now even the TS team won't add any more breakages of this rule...

Since functions must be able to call each other between files you have to think about this carefully! The transformations at the definition site and the call site must be fully independent of each other.

26

Hi all :waving_hand:,

I really like this proposal for optional named parameters — it addresses a real pain point in JS!

I wanted to add a concrete real-world use case from my work as a software engineer:

// Current JS positional call (ugly with many optional parameters)
ShowHideErrorMessage("Error", true, false, null, null, null, true);

// Using object destructuring today works, but is verbose
ShowHideErrorMessage({
    errorMessage: "Error",
    showImage: true,
    showInPopUpDiv: false,
    HideProcessing: true
});

Problems with the current approach:

  1. Must pass many null or undefined values for parameters I don’t care about.
  2. Order of parameters matters, making the call hard to read.
  3. Functions with 5+ optional parameters become messy and error prone.

What I’d like to see:

  1. JS functions support both positional and named parameters.
  2. Named parameters can be passed in any order.
  3. Defaults apply automatically.
  4. Optional mixing of positional + named parameters is allowed.

Example usage with proposed syntax:

// -------------------------
// Example 1: Positional first, named last
// -------------------------
// The first two parameters are passed by position.
// The rest are passed as a "named parameter object".
// Only the keys you care about need to be included.
ShowHideErrorMessage(
    "Error",           // errorMessage (positional)
    true,              // showImage (positional)
    {                  // named parameters
        HideProcessing: true,
        MsgType: "Critical"
    }
);

// -------------------------
// Example 2: Named only (order doesn’t matter)
// -------------------------
// All parameters are passed in a single object.
// You can include only the ones you care about.
// The order of keys inside the object does NOT matter.
ShowHideErrorMessage({
    errorMessage: "Error",
    showImage: true,
    HideProcessing: true
});

Why this matters:

  1. Reduces boilerplate nulls and undefineds.
  2. Improves readability and self-documenting function calls.
  3. Inspired by Python keyword arguments but adapted for JavaScript.

Thanks for considering this!

I’d love to hear feedback on how this could fit into the existing proposal and any potential edge cases I should consider.