You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would need rules to define commutativity and distributivity of conditional types
No obvious solution here
Possibly-useful observation: Extract<keyof T, "a" | "b"> is the same as (keyof T) & ("a" | "b") due to union-intersection distributivity and never-reduction
Now you have new problems!
Problem 1: Only certain provably-empty intersections get reduced, e.g. primitive-primitive collisions
We can't reduce other things like { __tag: void } & string because people use it for tagging
Also a problem due to non-object anonymous types like { toString(): string } which matches primitives
Problem 2: We don't have a built-in Exclude operator (subtraction types) for representing e.g.string - "a"
Should Extract / filtering operations be new primitives?
Does this actually solve anything?
No
... maybe a new operator for "strict" intersection that more aggressively culls impossible intersections
The correctness upside here comes with a downside of type display madness
The spooky ghost of "best common subtype"'s "first supertype of all other types" behavior returns
Could it be written with one fewer type parameter?
What should happen when inference produces a disjoint set of candidates?
Do something else?
We could sort inferences by type IDs, which would at least make this more likely to be stable
The problem is that we have to produce something when there are multiple candidates, and want that thing to produce errors (usually), but there's no good type to produce here that behaves correctly in all variance directions
Need some type that is not assignable in any direction
...
The text was updated successfully, but these errors were encountered:
I'm wondering if we're in a state where workarounds unsoundness and corner cases make things actually unintelligible for the - even experienced - end user?
That may not be the case and we may find a sweet spot but I'm questioning
./
?C:/foo
orhttp://example.com/bar
?//computername/module
?Falsy<T> | number
Falsy<T>
is a conditional type that produces a subset of"" | false | 0 | null | undefined
if (!x) { x; /*1*/ } else { x /*2*/ } /*3*/x;
for somex: T
x
should have typeTruthy<T>
, at 2 has typeFalsy<T>
x
would have typeTruthy<T> | Falsy<T>
due to how control flow analysis worksx
to go back toT
again at this point or the type is effectively unusableT | U
whereT
isW extends X ? Z1 : never
andU
isW extends X ? never : Z2
, for the sameX
,T | U
becomesZ1 | Z2
Extract<keyof T, "a" | "b">
is the same as(keyof T) & ("a" | "b")
due to union-intersection distributivity andnever
-reduction{ __tag: void } & string
because people use it for tagging{ toString(): string }
which matches primitivesExclude
operator (subtraction types) for representing e.g.string - "a"
Extract
/ filtering operations be new primitives?The text was updated successfully, but these errors were encountered: