Design Meeting Notes, 5/19/2017

[DanielRosenwasser]

Inference/Generic function composition requests

Issues linked to at the bottom.

---

• Why are we revisiting this?
  • Ben from RxJS filed an issue about general inference difficulties.
  • Will also be important for function pipeline in the future if it lands in ES.
• Currently we use inferences from values to flow into function parameters
• But we don't use the type that the result will flow into for inferences.

Example

type Mapper<T, U> = (x: T) => U;

function wrap<T, U>(cb: Mapper<T, U>): Mapper<T, U> {
    return cb;
}

function wrapStringToNumber(cb: Mapper<string, number>): Mapper<string, number> {
    return cb;
}

// works (not wrapped in a call)
let f1: Mapper<string, number> = s => s.length;

// works (types are concrete)
let f2: Mapper<string, number> = wrapStringToNumber(s => s.length);

// doesn't work because there are no parameters with known types
let f3: Mapper<string, number> = wrap(s => s.length);

What you'd like in the last example is that wrap(...) draws inferences from its contextual type.

But there are some problems with just using the contextual type.

// This works
let a1 = ["a", "b"].map(s => s.length);

// This doesn't - requesting the contextual type of `map`'s argument "fixes"
// its type parameters which don't have any inferences. This means that `s` gets the right type,
// but `a2` gets the type `Array<{}>`!
let a2 = ["a", "b"].map(wrap(s => s.length));

So basic idea for solution.

1. Draw inferences from arguments that are not contextually sensitive (e.g. values that are not untyped lambdas that we could give types to).
2. During the second round of inference...
   • if we run into a a contextually sensitive argument...
   • which needs a type parameter which has no inferences...
   • then reach out of the call and make inferences from the contextual type to the call's return type

Harder stuff involves inference between generic type parameters.
Not clear what to do here, but we can tackle it one step at a time.

---

Default imports for CommonJS modules

Want to align with Babel's emit - very difficult when people transition to using TypeScript and have to change their imports.

Biggest problem is that no way to tell which is "more correct" when you have a .d.ts that has top-level exports - is that a CJS or is it an ES module authored on top of CJS?

Entire thing needs a proposal.

---

Issues for Composition (instantiate generic signatures using contextual type instead of any)

Open:

• Supporting generic type inference over the other higher-order functions #9366

Duplicates:

• Higher order functions lose type parameters #417
• Generics not being inferred in complex case #9107
• question: how can i create and return a generic function in TypeScript? #9949
• Function composition challenge for type system #10247
• any inferred as type parameter even with --noImplicitAny #11311
• Wrong overload resolution with generics #11343
• Overload resolution: Choosing the wrong overload when arguments involve generic wrappers #13570
• noImplicitAny and generic arrow functions misbehave #13632
• Improve type inference for generic curried functions #15016

Inference from return type position

• Use return type as an inference location #11152
• Suggestion: Enable inferring the result type of a generic function based on the context in which it is used #3423

Higher order inference with generic functions

• Smarter type inference for functional programming (RxJS, Ramda, etc) #15680
• Function composition challenge for type system #10247

Comparing generic signatures

Open:

• Compiles without error when the return type signature of variable doesn't match that of the generic function that it is being assigned to #5616
• Use contextual signature instantiation to compare signatures #138

Duplicates:

• Inference bug #3038
• Unexpected behavior of generic constraints #3410
• generic constraint not working #3720
• Generic methods are not properly inferred when used as a value #5251
• Generic lambda identity function can cheat typesystem easily #8397
• unsound type constraints #8459
• Type inference for generic functions #11537
• Compiler allows violation of a generic function type interface #11877
• Generics return type check with arrow functions #13631
• Generic type constraint ignored when applied to interface expecting a different signature. #15458

[zpdDG4gta8XKpMCd]

been waiting for so long:

• Function composition challenge for type system #10247 (comment)
• Constraints cannot be proven in mapped types combination #13039 (comment)