Repository navigation
Disallow { a } #325
Description
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) }.
Activity
tabatkins commentedon Apr 12, 2024
That shouldn't be required.
{...a}is perfectly fine - it makes an object holding the remaining properties, then tests it against theapattern. Where are you seeing the restriction that requires parentheses?Jack-Works commentedon Apr 13, 2024
@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)orlet aljharb commentedon Apr 13, 2024
I'm confused, what else would
{ ...a }mean other than{ ...a: a }?Jack-Works commentedon Apr 14, 2024
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.
ljharb commentedon Apr 14, 2024
How is that different from any other object destructuring pattern?
Jack-Works commentedon Apr 14, 2024
In my example, x and rest is a binding, but y and rest2 is not.
ljharb commentedon Apr 14, 2024
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 commentedon Apr 15, 2024
Yeah,
{...a}is as different between pattern-matching and destructuring as{a}is. Both are consistent with their own rules, where the ident in...foois 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.
55Cancri commentedon May 7, 2024