Default values for nulls

# Michael Luder-Rosefield (15 days ago)

I know I am not the only one who has had several perfectly good use-cases for default values disallowed, because the value coming in was null, not undefined.

I cannot be the only one who has let bugs slip in because of failing to consider this case.

So, if we can find a non-confusing and simple way to alter the spec to allow for handling this, I imagine it would be considered useful and wanted.

The obvious candidate is the nullish coalescing operator, which is already part of the spec. Unfortunately, it is currently invalid to indicate default values with it. I can't see any reason against changing this.

function foo1 (x = 4) {
  console.log(x);
}

// currently causes SyntaxError
function foo2 (x ?? 4) {
  console.log(x);
}

foo1(null); // null
foo1(undefined) // 4

foo2(null); // 4
foo2(undefined) // 4

// currently causes SyntaxError
// should give x === null, y === 4
const { x = 2, y ?? 4 } = { x: null, y: null };

Dammit babies, you've got to be kind.

# Naveen Chawla (14 days ago)

What about allowing any expression then?

x || 4 x/4 x + 4 x + w //maybe allow only "previous" parameter values as scope x + a //SyntaxError: 'a' undefined in parameters scope

# Jacob Bloom (14 days ago)

I'd find it more readable to allow an assignment operator, with the semantic "do this transformation, using the passed value as the previous value"

function (x ??= 123) {} // If passed null or undefined, x = 123
function (x &&= 123) {} // If passed a truthy value, x = 123
function (x += 123) {} // Regardless of type, add 123 to x

That said, I can see how allowing the arithmetic-assignment (and concat-assignment) operators could lead hard-to-debug code that uses some "I am very smart" shortcuts, so I'd opt to start with the logical-assignment operators