[LOLCAT1024]

Maybe I did not express my self correctly, what I meant was - in it's current state the proposal rquires, when matching against an object, to specify all it's fileds, say you have an object with keys a, b, c then even if you match soley against the values of a , b you are required to specify c and by doing so notify it's existence. This poses a problem , since if you now remove c or add a filed d then the match will break failing to the default case , this means failing silently the worst that can happen. The described situation will be more then common since objects are ubiquitous to modern day js. Sadly nobody noted the existence of such a design flaw , which in my opinion is rather big since the proposal in it's current state implicitly turns objects into some kind of types , which they are not, such transformation will result only in increased coe coupleing , since anyone who matches against an object basically specifies it's type and as a consequence only doom and despare will follow to anyone involved.

[edflsafoiewq]

> in it's current state the proposal rquires, when matching against an object, to specify all it's fileds, say you have an object with keys a, b, c then even if you match soley against the values of a , b you are required to specify c and by doing so notify it's existence

I think this is wrong. The proposal says that a pattern like `{x}` matches if the object supports `ToObject` and if its `x` property is not undefined. It doesn't say anything about requiring that the object have no other own-properties. This is consistent with how destructuring already works in JS (it ignores any extra properties).