From 32b9ce0987cc46d282749ec4196e19a2e94b929f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= Date: Tue, 22 Sep 2026 09:14:58 +0000 Subject: [PATCH] :memo: Note two matcher gaps in the backlog Record the non-exhaustive broad-type hole in the primitive matcher and the never-typed handler parameters the tagged-union matcher produces when a property is a union, so both can be picked up as their own work units. --- backlog.tasks | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/backlog.tasks b/backlog.tasks index dc6eff8..9c1cc19 100644 --- a/backlog.tasks +++ b/backlog.tasks @@ -39,6 +39,10 @@ Testing: ✔ Run `npm run verify` and check the task off @done ☐ Test a literal union widened with `(string & {})` — `"red" | "green" | "yellow" | (string & {})` @medium → autocomplete should still offer the literals; arbitrary strings stay assignable and fall through to the fallback +☐ Type hole when using broad types like string as a universe @high + ☐ handlers cannot be exhaustive, yet it is possible to not have a fallback + ☐ one test even exploits this, I think for a negative test + ☐ does the same type hole exist for tagged-union matchers or primitive matchers only? Matcher: ✔ Clean up: adopt the 3-overload matcher (`src/prototype-ac2.ts`) and delete the prototypes @high @done @@ -55,6 +59,9 @@ Matcher: → `src/primitive.ts` / `src/primitive.test.ts` → `primitive-union.*` → `getMatcherW` → `getPrimitiveMatcherW` for symmetry with the tagged-union pair → update `src/index.ts`, `development/library.md` and any README references +☐ when using a union type as a property, the current behavior of tagged union matcher is + to pass never to handler parameters + → new matcher function needed or can be fixed in tagged union matcher Bugs: ✔ TS 7 LSP server logs `context canceled` on stderr at shutdown @done