Typescript: Design Meeting Notes, 8/4/2017

[DanielRosenwasser]

Trailing commas in type argument/parameter lists

https://github.com/Microsoft/TypeScript/issues/16152

• Argument lists and parameter lists both allow a trailing comma.
• Probably more confusing than it helps.
• Revisit if it ever comes up again.

Narrowing from index signature-originating properties

https://github.com/Microsoft/TypeScript/issues/17567

• Control flow analysis currently only operates on the declared types of properties.
  
  
  
  • There is no declaration in this case.
  
  
• Implementation takes place in getFlowTypeOfReference.
  
  
  
  • When we check if two references are the same, the symbols are the same.
  
  
• We agree that this is the behavior that should happen.
• Seems reasonable.
• Would the dynamic names PR be helpful?
  
  
  
  • Symbol table would be created during checking.
  
  
  • Probably stay out of that territory.
  
  
• Conclusion: mark as a hard-to-fix bug.

The promised type

https://github.com/Microsoft/TypeScript/pull/17077

• With the strictVarianceChecks and other changes, we created a difficult situation for Promise/PromiseLike inference.

• Today, if you have

  P.then(() => {
     if (doSomething()) {
         return 1
     }
     return Promise.resolve("abc");
  })
  

  Currently we end up with Promise<number | Promise<string>>.

• There seemed to be some fixes our team was looking at with how we infer between union types.
• This is difficult because now you have to get into some strange pattern-matching like behavior for unions.
• What about a negation type?
  
  
  
  • Doesn't give you recursive drill-down.
  
  

Promised type operator

ts async function f<T>(x) { y = await x; }

• Adds an internal PromisedType<T>, which can be described by a new type operator called promised T.
• "So this thing is hard-wired to Promise (or PromiseLike)?"
  
  
  
  • It's hard-wired to the functionality of await.
  
  
• Are there type relations described for this type operator?
  
  
  
  • Yes, it's on the PR.
  
  
  • Sounds like there is some strange behavior between how these types relate to each other.
    
    
    
    
    
    • Current rules seem to imply S -> promised T iff S -> T.
      
      
      
      
      
      
      
      • But what about S = string and T = Promise<string>.
      
      
      
      
    
    
    
  
  
• Difficulty here will be getting "higher order" type relationships correct.
• Also, you have to avoid going off the rails if your thens aren't the right thens.
  
  
  
  • We were already making sure this worked for await anyway.
  
  

Name bike-shedding

• No PromiseLike is ever assignable to the promise T.
  
  
  
  • More like the "eventual" of T.
  
  
  • await T?
  
  

Discussion among community

• People want a more generalized construct.
  
  
  
  • This is fairly specialized.
  
  
  • Well, so is await and .then in the first place.
  
  
• Array.prototype.concat exhibits same behavior
• Lodash has some problems here too.
• Array-flatten proposal will potentially complicate this.

Conclusion

• Examine type relationships further.
• Bikeshed on the name.
  
  
  
  • await, awaited?
    
    
    
    
    
    • These call attention to the fact that you're working with promises.
    
    
    
    • Point is to convey that it is strictly not creating a Promise/PromiseLike instance type.
    
    
    
  
  
  • fulfilled?
    
    
    
    
    
    • What a gross name.
    
    
    
    • Thesaurus suggests "consummated".
    
    
    
  
  

Non-null assertion type operator

https://github.com/Microsoft/TypeScript/issues/14366

• Semantics of higher-order relations could be complex.
• Would allowing a ! in typeof do what you want?
  
  
  
  • No.
  
  
• Why don't we always carve off null | undefined from T[K]?
  
  
  
  • Seems a little strange.
    
    
    
    
    
    • Not the same as the expression-looking operator.
    
    
    
  
  
  • Cases where you're using any under the hood?
    
    
    
    
    
    • Seems like a lot of those would be handled by constraints of keyof.
    
    
    
  
  
  • When do you not want this behavior?
  
  
  • We'll have to think more about it.
  
  

[masaeedu]

Well, so is await and .then in the first place.

Sure, but the problem is that you'll either:

1. Solve this problem over and over again (how do I refer to the return type of a function type? how do I refer to the value type of an array type? how do I refer to the Foo type of a Bar<Foo> type?), or
2. Leave everyone who doesn't have a broadly applicable enough instance of the same problem in the lurch

We can't change how await or Promises work, because TypeScript has to describe JS. We can however change the kinds of concepts TypeScript uses to describe JS.