Design Meeting Notes, 12/15/2023

[DanielRosenwasser]

NoInfer Type

#56794

• Fixes Suggestion: Noninferential type parameter usage #14829

• Alternative to Add NoInfer intrinsic type #52968 in an attempt to reduce internal conceptual overhead.

• Idea is to implement NoInfer via substitution types.

  • Substitution types are a kind of type that adds dynamic constraints in the true branch of a conditional type.

    type ElementType<T extends readonly any[]> = T extends 

  • Substitution types already need to be erased away back to the original type variable when possible.

• PR currently ensures that NoInfer stops all inner inference - means you don't have to write NoInfer directly on a type parameter, you can write around the entire type annotation.

  • But also means that NoInfer needs to stick around in a meaningful way in certain contexts.

• NoInfer can occasionally be immediately "evaluated" in a way where it's erased away when its inner type is known to be concrete.

  • But not for generics, and not for object types because they might contain generics.

• Some libraries ship their own NoInfer (e.g. ts-toolbelt), but it's "sticky" and doesn't defer on deeper object types.

  • So you can't say NoInfer on the entire argument types.

• How does this work with relating two types? e.g. instantiating one function in the context of the other?

  • The inference step not perform any inference between the two.

• How does this work on conditional types which... use the infer keyword?

  type KeyValueType<T> = T extends Map<infer U, NoInfer<infer U>> ? U : never;

  • You... don't infer to the infer type.

  • We know. Not optimal.

  • Technically could do this today with the following:

    type KeyValueType<T> = T extends Map<infer U, infer _ extends U> ? U : never;

    • Feels less bad in conditional types because there is no explicit type parameter list.

• Overall, feels right.