Empty object destructuring could tolerate null and undefined

[pygy]

In strict mode, this function declaration is a SyntaxError:

function third (_, _, x) {return x}

A nice alternative is

function third ({}, {}, x) {return x}

But then third(null, undefined, 5) throws a TypeError. It would be great if it didn't.

The change is AFAICT Web compatible since this is currently an error. It also seems logical to tolerate nulls here since the empty destructuring doesn't try to get anything from its source value.

This may be at odds with #1163 (or at least it would be useful to think both issues holistically).

Edit: cc @barneycarroll whose tweet triggered this message

[claudepache]

For me, {/* whatever */} as function parameter suggests an object to be destructured, regardless whether /* whatever */ is empty or not (and the emptiness of /* whatever */ might change in the course of refactoring); so that the TypeError in third(null, undefined, 5) is justified.

Instead of some clever hack, why not just use something boring like:

function third(_1, _2, x) { return x }
function third(dummy, dummy2, x) { return x }

?

[claudepache]

For me, {/* whatever */} as function parameter suggests an object to be destructured, regardless whether /* whatever */ is empty or not (and the emptiness of /* whatever */ might change in the course of refactoring); so that the TypeError in third(null, undefined, 5) is justified.

Instead of some clever hack, why not just use something boring like:

function third(_1, _2, x) { return x }
function third(dummy, dummy2, x) { return x }

?

[pygy]

Destructuring in function signatures is about binding, and function ({}, x) { return x } is in general a great, native way to say "Please don't bind any name to the first argument", not a clever hack.

FWIW, it already tolerates non-objects like strings, numbers and booleans.

Edit: we could alternatively devise a new third ( , , x) {return x} syntax, but I'm not a fan of those lone comas even though there is a precedent with [ , , ]. It would also make weird TypeScript/Flow type signature if you wanted your function to ignore the params, yet be picky type-wise about what it ignores.

[pygy]

Destructuring in function signatures is about binding, and function ({}, x) { return x } is in general a great, native way to say "Please don't bind any name to the first argument", not a clever hack.

FWIW, it already tolerates non-objects like strings, numbers and booleans.

Edit: we could alternatively devise a new third ( , , x) {return x} syntax, but I'm not a fan of those lone comas even though there is a precedent with [ , , ]. It would also make weird TypeScript/Flow type signature if you wanted your function to ignore the params, yet be picky type-wise about what it ignores.

[barneycarroll]

I support this proposal. I think explicitly destructuring to an empty object literal is clear enough in its intent to produce no reference: if the destructuring expression contained a property reference, then it's clear there would be a problem with interpolating undefined. As it is, the stated reason for the failure to destructure undefined values to {} don't match the stated rationale: it's perfectly possible to do this for non-nullish values, and since there's no attempted property interpolation it's not clear why nullish values throw.

[barneycarroll]

I support this proposal. I think explicitly destructuring to an empty object literal is clear enough in its intent to produce no reference: if the destructuring expression contained a property reference, then it's clear there would be a problem with interpolating undefined. As it is, the stated reason for the failure to destructure undefined values to {} don't match the stated rationale: it's perfectly possible to do this for non-nullish values, and since there's no attempted property interpolation it's not clear why nullish values throw.