Design Meeting Notes, 12/4/2020

[DanielRosenwasser]

Array.isArray Changes

#41808

• We did this work to play better with ReadonlyArray.
• The change works well, but works terribly with generics.
• Are we willing to have worse behavior in the 0-order case for the higher-order case?
• So are we reverting?
  • Transparently better change,
• Conclusion: let's revert.
  • Reopen original issue and mark as "design limitation"

Signature Relation Changes that Affect Overload Resolution

#41563
#41607

• If you have a callback that takes an optional paramerter.
• Was reported as an issue with promisify, but with bad types. Got around it with a type-assertion.
  • Comes up with callbackify.
• 4.0 behavior is hard to justify.
• This needs to model the way the function works by checking fn.length
• Hyrum's Law 😬
• callbackify is wrong in both old/new versions of TypeScript.
• Impact seems limited, but on highly-used functions.
• Can't simply revert, it fixed a crash.
• Experiment with mitigations?

Explain Why Files are Included

#40011

• "hey, I don't understand why this file is in my program"
  • @types auto-inclusion
  • lib settings people don't understand, or a lib reference that came up somewhere.
  • "Can't overwrite input file", "but what is it an input file?"
• --listFiles
  • That's cool, we could augment the output, but VS uses the output of --listFiles so it's a hard dependency.
• --explainFiles
  • --explainInputFiles
  • Supposed to be human-readable.
• ASCII-graph rendering!
  • Harder to grep.
• Maybe this is at odds with grep-ability, but would be nice to see separate sections just for the file list.
  • listFiles?
    • No, doesn't do this.
  • showConfig?
    • No, show include file patterns.
• Can this tell people when the option originates from a different tsconfig? Or just which tsconfig.json an option comes from?
  • User might be able to figure out where a compiler option came from.
• Option could've been specified on the command line.
• "DO NOT DEPEND ON OUTPUT" warning?
  • No.
• Emoji to push people away from depending on the output?
  • Nah.

typeof class .d.ts emit

#41587

declare let x: typeof abstract class C {};

let y = x;

• In this example

  • x has the original type.
  • y gets rewritten to the "equivalent" class.

• Switching to new output isn't backwards-compatible.

• Also, if you add a private member, it's not representable, or if you try to reuse the original syntax, it would be nominal.

  // These are incompatible.
  declare let cc1: typeof class C { private yadda: string; }
  declare let cc2: typeof class C { private yadda: string; }

• Can you use typeof cc1?

  • Why cc1 and not cc2?

• Feeling: when classes are anonymous and don't have a symbol you can refer to, maybe those types should be compatible?

• We must have logic for doing this with unique symbols.

• We also have special logic for this in the JS declaration emitter.

  • Doesn't have to do this for TypeScript, but it does for JavaScript.
  • Back to "Why cc1 and not cc2?"
    • Generate an anonymous thing for the JS case.
    • Not what we've done before for TS.

• Striving to give working .d.ts output without errors would be more ideal all-around.

function foo(): typeof class { private x: string } {
    return class { private x = 32 };
}

• Are those compatible???? 😅
• 😬
• Nominality throws a very big wrench in this.
  • Yes, and nominality is a very bad idea unless you always have a well-known name for a symbol..
• Generate a name?
  • How do you ensure the name is stable?
  • Doesn't have to be if it's not publicly accessible.
  • But across modules, you might still need to refer to the name - now do you copy the whole class over?
  • Still could generate it.
• Generating a name feels like a bad mitigation strategy that simulates the the structural type system in a nominal way.
• Could translate the same arguments to unique symbol
  • Every unique symbol was declared as the inferred symbol of a declaration.
  • Same issues though.
• Can hold off on the feature, doesn't make the world worse...
  • We can report errors on .d.ts emit, but it may still be a frustrating experience.
• Seems like the problems are only in .d.ts emit.
  • Appetite for only explicit annotation syntax?
• Frustrating because a lot of the motivation for this was .d.ts emit for mixins.
  • But we partially wanted this to avoid generating top-level classes. If we have to do that anyway...
• Well, it is nice to be able to write a type out without static/instance decomposition.
• Keep in mind, we might want a "raw" mode for .d.ts emit in the future.
  • Rehydratable? At least comparable.
    • Just use the whole file as a hash? New flag assumeChangesAffectShape for incremental and watch scenario #41219
• Consensus?
  • Don't do it if we're not excited and feel unsure.
  • Defer from 4.2 for now.

React Native .d.ts Changes

DefinitelyTyped/DefinitelyTyped#49914

• The environment problem
  • styled-components/native relies on the react-native types.
  • Moving that out to styled-components-react-native.
• Won't this affect ATA?
  • Probably will not pick it up.
• What exactly is the issue?
  • Conflicting defs between the DOM types and react-native (which depends on Node types).
• How is the world not blowing up today?
  • skipLibCheck?
  • patch-package?
• We don't have a good gauge to understand how people are already doing this, and we're not sure what the tolerance is for this change.