can not match empty object

[concavelenz]

With regard to https://github.com/tc39/proposal-pattern-matching#objects-closed-by-default

Allowing extra properties by default does not provide a means of matching objects without additional properties, {x,y} without property "z", the empty object {}. Requiring explicit ... is strictly more powerful.

It seems odd that it is possible to match empty array but not empty object.

[notriddle]

It would still ignore hidden properties, like constructor and __proto__, and properties that come from the prototype, right? So the {} pattern would match an {} expression, Object.create(null), and an empty array [] (since length is hidden).

[tabatkins]

Length of an array is pretty core to the concept of what the array is; the precise set of properties owned by an object does not have the same semantics. As @notriddle notes, most objects will have several non-enumerable properties inherited from Object or just intrinsic; additionally, subclasses will generally have more properties than the superclass, but it's natural to match a subclass instance when you ask if it's a superclass (both respond true to instanceof Superclass). Finally, I think it'll be most common that only some of the properties of the object will be relevant in a given match.

So, if we fail for object with more properties than requested, we'll have to add some corner-case handling by default anyway, and authors will commonly get spurious match failures if they forget to include the .... I think the cases where you want to allow additional properties are more common than wanting a precise object shape (again, ignoring the always-present properties).

[zkat]

Hey y'all! #65 has gotten merged, and a lot of issues have become irrelevant or significantly changed in context. Because of the magnitude of changes and subtle differences in things that seem similar, we've decided to just nuke all existing issues so we can start fresh. Thank you so much for the contributions and discussions and feel free to create new issues if something seems to still be relevant, and link to the original, related issue so we can have a paper trail (but have the benefit of that clean slate anyway).

As far as this specific one goes: I think the new semantics for object matchers are The Right Thing™ (because partial-matching of objects is such a common thing to want and requiring ...x is a footgun for this). You can achieve whatever kind of "empty object" matching you want (since this varies) using guards:

match (x) {
  x if (_.isEmpty(x)) => ...
}