Design Meeting Notes, 1/28/2022

[DanielRosenwasser]

Instantiation Expressions

#47607

• The ability to take a generic function and supply type arguments and instantiate the signatures.

• You could've done this with a type assertion: f as (some: Type, params: OtherType) => RetType

  • Often cumbersome.
  • Also more error-prone.

• This works across both functions and constructor functions.

• From the JS emit perspective, this is the same as if you'd omitted type arguments completely.

• This gets rid of an unnecessary pattern people used where they'd create a subclass to specialize a constructor.

  class ErrorMap extends Map<string, Error> {}
  
  // no more!
  
  const ErrorMap = Map<string, Error>;

• Also opens up some use-cases where ReturnType didn't work well, because you can now create your own type parameter, and create a locally-concrete instantiation and fetch the return type of that function type.

  declare function someFunc<T>(x: T): { value: T };
  
  // Identical to '{ value: LocalT }'.
  type Foo<LocalT> = ReturnType<typeof someFunc<LocalT>>;

• No type arguments? (f<>)

  • That's always an error - you always need at least one.

• Type argument list where nothing applied?

  • That's an error.

• What if you have f<TypeArg>.prop?

  • Doesn't make any sense - it doesn't do anything you would possibly want. No difference between f<T>.prop and f.prop.
  • Nonsensical, but can you parenthesize your way out of it?
    • Yes.

• Any parsing weirdness?

  • How we parse across lines.

    // CallExpression with type args - differs between JS and TS
    f<T>
    (someArgs);
    
    // PR maintains JS behavior as a relational expression.
    f<T>
    someVal

  • Set of symbols that tell us if these type arguments can be parsed.

• What about a new form of type operators that creates a deferred type application across signatures, similar to indexed access types?

  • Example?

    function f2<T extends <A>(x: A) => A, U extends <B>(y: B) => B>(f: T | U) {
        // what is the type of this?
        // T and U are generic, but currently this is not
        f<string>;
    }

  • When would the two be materially different?

    • When T or U have multiple overloads.
    • When T or U return an intersection for their return type.

  • Could do that, but we lack a type operator to do that in the type space (as opposed to the value space here).

    function f2<T extends <A>(x: A) => A, U extends <B>(y: B) => B>(f: T | U) {
        // need some operator for "applying type arguments to the signatures"
        // let's use faked up syntax like `%`
        let g: (T | U)%string = f<string>;
    }

Ambiguity With Arrow Function Return Types and Conditional Expressions

#16241

x ? y => ({ y }) : z => ({ z })

• Ambiguity - are these
  • two arrow functions - y => ({ y }) and z => ({ z }) in a conditional expression, or
  • two nested arrow functions, where z the return type of the arrow function ({ y }): z => ({ z })
• Want to disallow the TS interpretation of two nested arrow functions.
• Need to see what this breaks.