* #25826 Inference of `pipe`-like functions * No obvious solution that doesn't break other stuff * The only real fix would be full unification * #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 #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 (#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>`, then `Foo<T, U>` is *different* from `Foo<T, U, >` * Gross * Not much consensus for `*` or `auto` or `infer` * 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! * :+1: for `*` * Semantics are good to go * Fallout from #26405 Narrowing mapped types * "Is maybe assignable to" is almost the same as "Is comparable to" * Break in RWC in `T | T[]` with `T` = `{ x?: string }` * Kinda wat because `T[]` *is* also `T` for weak `T` * Control flow is based on removal of constituents of unions * It's "incorrect" to remove `T` from `T | T[]` in the `AOrArr<T>` example * Remember that weak types are comparable to but not assignable to most target types * Would we rather have #26130 or #26405? * #26130 - not a regression, but weird * `T | T[]` with weak `T` is suspect but not uncommon * (Debate about *why* #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 * #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 * #26281 for next week along with Nathan's inference-based refactors
pipeis incorrect when strict mode is disabled #25826 Inference ofpipe-like functionscreateTypefail, but it's not clear what to do afterwardsFoo<A, B, C = string>, thenFoo<T, U>is different fromFoo<T, U, >*orautoorinfer*is the best*T | T[]withT={ x?: string }T[]is alsoTfor weakTTfromT | T[]in theAOrArr<T>exampleneverwith strictNullChecks #26130 or Narrowing on assignment does not remove weak types #26405?neverwith strictNullChecks #26130 - not a regression, but weirdT | T[]with weakTis suspect but not uncommonneverwith strictNullChecks #26130 happens)&&in non-SNC