Disallow { a }

[Jack-Works]

Current spec does not allow { ...a }.

You have to write { ...let a } (bind rest to a) or { ...(a) } (test rest with a, where a might be a custom matcher) depends on your intension.

I think we should also do this to { a, b: 1 } to disambiguate { a: a, b: 1 } (match with a) with { b: 1} and has "a" (has a property in it).

Currently, { a } means and has "a".

Or we can do the other way, allowing { ...a } to be { ...(a) }.

[tabatkins]

You have to write ... { ...(a) }

That shouldn't be required. {...a} is perfectly fine - it makes an object holding the remaining properties, then tests it against the a pattern. Where are you seeing the restriction that requires parentheses?

[Jack-Works]

@tabatkins it's in the spec as a not-consensused-yet feature. I identified them as footguns and therefore included them in the spec. { ...a } in a pattern has slightly different meaning with in the destructing, therefore it's better to ban it and require explicit clarify of what developer means (a) or let a

[ljharb]

I'm confused, what else would { ...a } mean other than { ...a: a }?

[Jack-Works]

I'm confused, what else would { ...a } mean other than { ...a: a }?

It means collecting rest properties in the destructing and binding it to a variable out of pattern matching. Developers might think it has the same meaning inside pattern matching.

const { x, ...rest } = obj
if (obj2 is { y, ...rest2 }) {
    // ?? y and rest2 are not bindings!!
}

[ljharb]

How is that different from any other object destructuring pattern?

[Jack-Works]

In my example, x and rest is a binding, but y and rest2 is not.

[ljharb]

Yes, I agree this is a difference between destructuring and pattern matching - it has nothing to do with rest properties or with the concise form, though.

If we don't want that discrepancy, we'd need to revert to our previous version that had ${} and implicit bindings, which already got pushback.

[tabatkins]

Yeah, {...a} is as different between pattern-matching and destructuring as {a} is. Both are consistent with their own rules, where the ident in ...foo is interpreted the same as the value in {key: foo} - in pattern-matching it's a pattern in both places, and in destructuring it's a name binding in both places.

It would be fairly bad to change this, imo.