Design Meeting Notes, 2/17/2021

[DanielRosenwasser]

Avoiding void | undefined Breaks in Literal Type Reduction

#42846

• When we did the work to optimize literal type reduction, we added a missing reduction from undefined to void.
• This was already part of subtype reduction, not literal reduction.
• Broke T | void | undefined - nonsensical.
  • Not exactly nonsensical. Promise<void> in Rome's tools.
  • Tried fixing, much more complex.
  • Would want to improve here.
• This caused a lot of breaks, but really it's trivial to revert this behavior.
• There was existing work to avoid certain special cases of void | undefined reduction and Promises. Do we still need that?
  • Improve react's no-return hack for TS 4.3 DefinitelyTyped/DefinitelyTyped#51081
• Conclusion: Revert for 4.2

Discriminated Union Targets, and Subtype Reduction Questions

#42522
#42556

const test: Action[] = [
    { type: 1, payload: 42 },
    { type: 2, payload: 42 },
    { type: 3, payload: 42 },
];

• Today
  • 1, 2, and 3 get contextually typed, become literals.
  • We then try to figure out the type of the array. Create a union of each types, then subtype-reduce them.
  • Useless subtype pass - do a lot of work, all of these types are distinct.
• Proposed
  • Know that you're about to assign and have a contextual type, don't try to do subtype reduction.
  • Then just leverage the literal discriminants to build a hash table, detect compatibility on each member.
• Issues with proposal
  • If you don't reduce the type inferred from an array literal, you end up with HUGE types that often contain effective duplicates.
• Could imagine something where you reduce against Action instead of a full subtype reduction pass.
  • Still doesn't avoid the fact that subtype reduction is quadratic when it comes into play.
• It always feels strange that subtype reduction is lossy.
• Have some ideas, but maybe loopy literal types cause issues with cleaning up types for error messages.
• Thought: beyond a certain number of elements, it may not be worthwhile to perform subtype reduction.

const enum Awfulness

microsoft/FluidFramework#5070

• 3 core groups impacted in discussing const enums
  • I want inlined enums, I'm an app
  • I want inlined enums, I'm a library
  • I need to just consume enums, I use isolatedModules
• Inlining as numeric literals in all our switch statements and whatnot had a massive impact on perf.
• Question: depends on perf?
• Some way of saying "I want to use const enums in my app, but when I produce a declaration file, they should not appear as const enums."
  • What about monorepos? Project references?
• Maybe make it harder to use const enums? Unclear what it does for you.
  • Unclear if stick is better than carrot.
• If you --preserveConstEnum, maybe the .d.ts file shouldn't say const enum?
• Also, shouldn't dictate which enums get inlined.
• From the declaration file, you don't know if the enums were emitted or not.
• If they were emitted, maybe we should just remove the word const.
• --preserveConstEnums as a tristate? New flag?
• But not all libraries have the same intent of what const-ness mean.
  • Being able to configure this per library would be nice.
  • But would love to not need to though. That's ideal.
• Check with the Fluid team on whether const enum is a hard constraint.
• We do like the idea of emitting enums implying that they're not const in declaration files.