Closed
Description
- Generic inference inside of
pipe
is incorrect when strict mode is disabled #25826 Inference ofpipe
-like functions- No obvious solution that doesn't break other stuff
- The only real fix would be full unification
- keyof and type parameters can produce huge types that hang/crash compiler #25942 OOM crash or non-ending computations
- Can we limit ourselves in some way to prevent OOMs?
- We could make
createType
fail, but it's not clear what to do afterwards - The type here is not particularly deep, just wide
- No obvious problem is detectable during checking
- See also [Bug]tsc does not finish #26314
- What useful thing could we do if we detected we were about to OOM?
- Throw?
- Try to "stop" checking?
- Throw a special exception to disable the LS
- What about hangs?
- Would need VS / VS Code to support some kind of detection
- Keep trying to find a solution
- Partial type argument specification and named type arguments (Implement partial type argument inference using the _ sigil #26349)
- How does the call site specify the inference positions?
- Difficulty is that default type parameters exist
- We need some placeholder
- Big breaking change to switch nonspecified parameters to inference
- Presume you have
Foo<A, B, C = string>
, thenFoo<T, U>
is different fromFoo<T, U, >
- Gross
- Not much consensus for
*
orauto
orinfer
- What about inferring only when no default exists?
- More subtlety
- OK maybe
*
is the best - What's the use case?
- Vue
- Why aren't Vue's type parameters in the "right" order?
- One person made a mistake and now we're stuck with it!
- 👍 for
*
- Semantics are good to go
- How does the call site specify the inference positions?
- Fallout from Narrowing on assignment does not remove weak types #26405 Narrowing mapped types
- "Is maybe assignable to" is almost the same as "Is comparable to"
- Break in RWC in
T | T[]
withT
={ x?: string }
- Kinda wat because
T[]
is alsoT
for weakT
- Kinda wat because
- Control flow is based on removal of constituents of unions
- It's "incorrect" to remove
T
fromT | T[]
in theAOrArr<T>
example - Remember that weak types are comparable to but not assignable to most target types
- Would we rather have Generic lookup type wrongly narrowed to
never
with strictNullChecks #26130 or Narrowing on assignment does not remove weak types #26405?- Generic lookup type wrongly narrowed to
never
with strictNullChecks #26130 - not a regression, but weird
- Generic lookup type wrongly narrowed to
T | T[]
with weakT
is suspect but not uncommon- (Debate about why Generic lookup type wrongly narrowed to
never
with strictNullChecks #26130 happens) - Don't add a new type relation yet - high perf cost and new subtleties
- Roll back the fix for now and try to think of other fixes
- And expression inferrs wrong type. #26468
&&
in non-SNC- The rules are ancient and also bad
- Right operand is a good answer for non-primitive LHSes in non-SNC but bad for primitives
- Fun breaking change
- Isn't all of this code extremely suspect?
- See what's in RWC
- Everyone should turn on SNC!
- No urgency
- Distribute indexed accesses when simplifying them #26281 for next week along with Nathan's inference-based refactors