Typescript: Design Meeting Notes, 5/10/2019

[DanielRosenwasser]

Perf edition!

Fix relations of instantiations of the same signature

https://github.com/microsoft/TypeScript/pull/31029

• Problem is that when we relate signatures to each other, we erase type parameters to anys.
• We have a fix for that, but nowadays whenever we have a fix we also have a break.
  
  
  
  • It blows up types for styled-components/v3 blows up with an out-of-memory (OOM) error.
  
  
  • And it breaks Ember's Observer type (which is actually invarian) and the addObserver method whose methods take a key and a value for the current type.
  
  
  • The more recent styled-components increases in type-checking time.
    
    
    
    
    
    • About 2 seconds.
    
    
    
  
  

Now we're talking about

Slow completions

• Completions have slowed down nowadays as well, partially because we check against the this type to decide whether we should even show methods in the first place.
• Wesley: The problem is that we do a fully structural check, but we fundamentally need to make that cheap somehow.
  
  
  
  • One idea is that we need to be able to keep the constraint from the false branch of conditionals to short-circuit operations (by not eagerly evaluating conditionals)
  
  
  • Introducing negated types would be problematic for reasoning about, display purposes.
  
  
  • Worth trying at least.
  
  
• Could also try to avoid instantiations of conditionals using infer types.
• We also don't cache the results of what conditional inference does.
• One other thing is we need to be able to help inform people whether their DefinitelyTyped changes are going to cause regressions so we can judge whether more accurate types are "worth it".

Action items:

• Fixes for Ember types (@ahejlsberg)
• Remove this parameter filtering in completions. (@weswigham)
  
  
  
  • https://github.com/microsoft/TypeScript/pull/28692
  
  
• Defer merging #31029 (@ahejlsberg)
• Investigate negated type fixes (@weswigham)

Caching control flow results across invocations

31003

• Minor slowdowns and increased memory usage by adding the change, but fixes crazy-long cases with assignments on the LHS.
• Why doesn't the test case cause an issue?
  
  
  
  • Element access assignments can't be cached, these can.
  
  
• Resolution: merge for 3.5.

Array spread emit fixes

https://github.com/microsoft/TypeScript/issues/8856
https://github.com/microsoft/TypeScript/issues/31166

• The way that we emit array spreads in ES5 is incorrect because we use concat and that omits missing elements.
  
  
  
  • In --downlevelIteration, this works right, but not otherwise.
  
  
• We had an initial version that was slower, but still didn't affect the compiler much.
  
  
  
  • A community member suggested something that's faster, is almost as fast as the original.
  
  
• Resolution: approved, but for 3.6

[falsandtru]

@DanielRosenwasser Why you don't address #31148?

[MartinJohns]

@falsandtru Because time is limited, and they did not get to discuss your favorite issue.

[falsandtru]

@MartinJohns Looks like you don't have any ability or position to evaluate the problem.

[MartinJohns]

That's a rude and silly thing to say, but even if it would be true it would be irrelevant. You asked why they did not address your issue in the design meeting notes, and I gave you an answer. I don't need to have any special abilities or a position in the TypeScript team to give you this answer. It's just common sense.

The TypeScript team consists of humans, and they have limited time. They prioritize the issues and then discuss the issues on top of their list. Your issue was not on top of the list and there was not enough time to discuss all issues.

[falsandtru]

FYI, blocking a voice of the person concerned is no common sense. It is a behavior of dictators. Thanks.

[zpdDG4gta8XKpMCd]

might be related https://github.com/microsoft/TypeScript/issues/30696#issuecomment-478799258

[DanielRosenwasser]

@DanielRosenwasser Why you don't address #31148?

The most critical thing we are dealing with right now is performance issues that were introduced in TypeScript 3.4. Array spread behavior is one of our most upvoted issues and it has a clear solution.

[falsandtru]

I've no objection to the current items but #31148 is an important and deep-rooted problem which breaks TypeScript ecosystem on npm. So I think you should keep your team informed about it to find a solution.

[RyanCavanaugh]

@falsandtru thanks for your feedback on prioritization. We can't change what we discussed in a meeting that occurred in the past, but will keep evaluating feedback in this area. You might also want to track #18588 since it relates to your concerns.

[falsandtru]

Thanks for your correct info. I move to there. However, I think that solution will be a workaround but probably it is not the best.