`void` and pattern matching

[gkz]

My concern with using void for this purpose in pattern matching, e.g. this example:

match (obj) {
  {x: void, y: void, ...rest}: ...
}

Is that in this context, I believe a reasonable interpretation (and perhaps one that comes to mind first for those not familiar with this feature) would be that we are matching for objects that do not have the properties x and y (or that they are undefined), given that it looks like we are "matching against void", rather than the properties x and y exist and can be any unknown value. This is because the void operator returns undefined, and type-systems like TypeScript and Flow use void as a type for either undefined or the lack of a value (i.e. void return).

I hope we can use _, even if only in the context of new syntax like extractors or match

[ljharb]

I think that confusion is just part of destructuring syntax - if you had { x: a, y: b } with the interpretation above, you'd think it's checking that x is a property that matches a, instead of just renaming to a.

If you know it's renaming, then "renaming to void" makes sense and is exactly what it's doing.

[gkz]

My concern is specifically about pattern matching, where I believe match (input) { {x: "foo"}: ... } matches when input has a x property with value "foo".

[rbuckton]

Negation in pattern matching is governed by not. { x: void } means "must have x, discard the value". not { x: void } means "must not have x". The meaning of void is only potentially ambiguous until you've become accustomed to the syntax.

[rbuckton]

Another way to think of it is that { x: void } matches that a property named x exists and its value is consigned to an endless void of nothingness. A bit poetic, maybe, but a meaningful distinction.

From a type systems perspective, void can have this connotation as well:

function f(cb: () => void) { }
function g(): number { return 1; }

f(g); // type checks fine as the return type/return value are discarded.