Pattern Matching Champions
2024-04-08
plaintext logs
prev next
source on github
22:41
<rbuckton>

In the proposal {} explicitly matches Object, but destructuring does not. By restricting {} to Object you can't have patterns like

match (value) {
  when String & { length: 3 }: ...;
}
22:42
<rbuckton>
IMO, the only things that shouldn't match {} are null and undefined.
22:43
<ljharb>
+1, TS got this one right
22:43
<rbuckton>
https://tc39.es/proposal-pattern-matching/#sec-object-pattern-matches, every single Step 1.
22:44
<ljharb>
yeah that seems like an oversight.
22:44
<ljharb>
{ length: 0 } needs to match an empty string, for example
22:46
<rbuckton>
It does mean that restricting things to a spec Object is a bit more complicated, though hopefully that can be handled by when Object: even for functions
22:46
<ljharb>
when Object indeed must match anything for which Object(x) === x
23:06
<rbuckton>
Probably still a little too early for a thorough review of the spec, but I noticed that https://tc39.es/proposal-pattern-matching/#sec-match-expression-clauses-runtime-semantics-evaluation only cares about ECMAScript language values rather than completion values, which doesn't work as it prevents ThrowCompletion from bubbling out of match (or return/break/continue in the event do expressions are supported).