Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 5/8/2020 #38598

Closed
RyanCavanaugh opened this issue May 15, 2020 · 2 comments
Closed

Design Meeting Notes, 5/8/2020 #38598

RyanCavanaugh opened this issue May 15, 2020 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@RyanCavanaugh
Copy link
Member

  • PR Consistent narrowing by discriminant #38311 More-consistent narrowing
    • Fixes long-standing issue
    • Design limitation was due to some caching issues
    • Singleton types still won't narrow to never, which is generally the desired behvioar
  • Named tuples
    • Switching to parameter-style syntax based on poll feedback
    • All names must be present or not present
    • Names are preserved through most transforms
    • Good to go for 4.0
  • static index signatures on classes
    • ASI issues in parsing
    • Final approval 👍
  • Exponential increase in compile time and memory usage #38339 performance issues
    • Caused by massive unions (JSX.IntrisicElements[keyof JSX.IntrinsicElements]) going through subtype reduction
    • Keep investigating
@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label May 15, 2020
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented May 15, 2020

I ended up taking notes as well 😬

More Consistent Narrowing

#30557

  • Unless the declared type is a union, we don't do discriminant narrowing.
  • In a lot of cases, people start out with a declared type of unknown, guard down to a discriminated union, and then try to do a discriminant check.
    • Users are often very surprised by this.
  • Idea: if the declared type is a union, use that. If not, use the currently-narrowed type.
  • Why can't we always use the computed type?
    • The problem is that if you had a singleton value type - do you really want to narrow that down to the never case?

Labeled Tuples

#28259

  • Got language service support working
    • Doc comments seem to be tracked around
  • Based on polls, we'll have to swap the syntax a little bit.
  • What about mixing unlabeled and labeled?
    • Not possible.
    • "Gracefully handled" by giving them no name for any subsequent analysis.

Time Blowup

#38339

  • Spending time in subtype reduction on massive types that are...actually the same type!
  • But even if they weren't the same types, this takes a long time!
  • Subtype reduction - is it worth it? Really, these types should be the same!
    • Also, for a union of 100 members...maybe who cares!? The point is usually to make the unions are small.

@AviVahl
Copy link

AviVahl commented May 16, 2020

Not sure if I'm the first one to suggest it... Any chance you guys could video record and upload these meetings? :) (like Node.js does)

Would be really nice to be "a fly on the wall".

EDIT: heck, it's 2020, make a live stream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

3 participants