Unexpected UnmatchedPatternError

[qwelias]

match({ a:{/* whatever */} }, [
  ({ a }) => console.log(a.whatever),
]);
// UnmatchedPatternError: Unmatched pattern

Expected:
undefined

[RReverser]

Yeah, this is another known issue I thought of but hadn't time to write down to "known issues" yet. I'll try to fix this one, thanks.

[RReverser]

The only way to fix this w/o changing syntax (at least the only I can think of) would be to track error.stack location and take current matcher's .toString() to check whether we're in destructuring or in the function body position. But that will make performance even worse.

If changing syntax, it's quite easy to add intermediate step like

match(obj, [
	({ x }) => () => console.log('x', x),
	({ y }) => () => console.log('y', y),
	({ z }) => () => console.log('z', z),
	// Exhaustive match; will throw `xmatch.UnmatchedPatternError` unless uncommented:
	// other => console.error('Something else', other),
]);

but I don't really like it...

One another way would be to add unguard symbol or function that user would need to manually call or destructure to allow unknown properties on object again.

I'm not sure what would be the cleanest way yet, but I'm open to suggestions.

[qwelias]

The intermediate step approach seems like the most sane one: little-to-none performance impact, no need to unguard every desrtuctured variable (human error prone), and it would just work.

[RReverser]

Actually got one more idea how to do it: similarly to how I just implemented iterable support, I can detect end of iteration for unwrapping. In that case, one one hand, match will require its arguments to always be an iterable / array, but on another, syntax change might look relatively unobtrusive:

match([ obj ], [
	([{ x }]) => console.log('x', x),
	([{ y }]) => console.log('y', y),
	([{ z }]) => console.log('z', z),
]);