Typescript: Design Meeting Notes, 5/8/2020

Created on 15 May 2020  路  2Comments  路  Source: microsoft/TypeScript

  • PR #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 馃憤

  • #38339 performance issues

    • Caused by massive unions (JSX.IntrisicElements[keyof JSX.IntrinsicElements]) going through subtype reduction

    • Keep investigating

Design Notes

Most helpful comment

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.

All 2 comments

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

https://github.com/Microsoft/TypeScript/issues/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

https://github.com/microsoft/TypeScript/issues/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.

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.

Was this page helpful?
0 / 5 - 0 ratings