Pattern Matching Champions
2024-03-26
plaintext logs
prev next
source on github
14:45
<rbuckton>
The current semantics of InvokeCustomMatcher don't work well for extractors due to the SameValueZero and SameValueNonNumber semantics on steps 1 and 3. I would expect that steps 1 and 3 would return false when kind is ~list~, since a Foo(x) is invalid if Foo isn't a valid matcher since an iterator is expected.
15:01
<rbuckton>

Also, step 10 and 11 say:

  1. Perform ? GetIteratorCached(result, cacheGroup).
  2. Return result.

Why are we not returning the iterator here? I was hoping to avoid dragging in all of the caching logic for non-pattern Extractors, but if I want to reuse InvokeCustomMatcher it seems like I would need to do so.

15:16
<rbuckton>
We also still need to narrow down whether receiver makes sense, or whether there are other ways to accommodate those cases (i.e., a getter returning a bound function, etc.).
15:18
<Jack Works>
The current semantics of InvokeCustomMatcher don't work well for extractors due to the SameValueZero and SameValueNonNumber semantics on steps 1 and 3. I would expect that steps 1 and 3 would return false when kind is ~list~, since a Foo(x) is invalid if Foo isn't a valid matcher since an iterator is expected.
Yes. It's a bug, actually it fails the spec assert "Assert: listSubject is an Object.". In the ~list~ mode, it should throw.
15:23
<Jack Works>

Also, step 10 and 11 say:

  1. Perform ? GetIteratorCached(result, cacheGroup).
  2. Return result.

Why are we not returning the iterator here? I was hoping to avoid dragging in all of the caching logic for non-pattern Extractors, but if I want to reuse InvokeCustomMatcher it seems like I would need to do so.

Oh it's another bug, there are some type mismatch here
15:46
<Jack Works>
fixed in https://github.com/tc39/proposal-pattern-matching/commit/ac676440bcbff5be7b87791fdafdfeeab64cbd44#diff-7d681727fcf47dc0b9a7512a470fb0da63276c625891a5cc232d725bd12912fd