Feedback on Strict Optional Properties

#44421

• VS Code got 5K errors
  • Same-ish number of errors as strictNullChecks - does it provide the same value as strictNullChecks.
• Still feel like it's a feature we deliver, unclear how we can deliver as-is.
• Options
  • Compiler option, but not in --strict.
    • Pro: Not invasive under --strict.
    • Con: no "forcing function" to update all of the world's declaration files.
  • New sigil: ?!, !?, [[interrobang jokes]], etc.
    • Pro: not breaky
    • Con: opt-in, pretty subtle
• Seems similar to noUncheckedIndexedAccess.
• Most people seem to be in favor of decoupling from strict
  • noUndefinedOptionalProperties
  • noUndefinedWritesToOptionals
• Wouldn't have had noUncheckedIndexedAccess if we started today.
• Could put it under --init.
  • Gotta update lib.d.ts and DefinitelyTyped.
• Round-tripping between JSON stringify/parse?
  • We don't preserve any info around that
• Gotta update the DOM, lib.d.ts
• tsc --init?
  • Without an opt-in flag, we have to take the stance about what it means to write ? on a property, and what we want the community to do.
  • The transform is easy, but updating libraries is hard - what happens when someone uses Partial? Can't change a library's interpretation of Partial.
• Partial? Should it include | undefined?
  • We added Partial for setState...
  • Extra type parameter to Partial?
    • No.
• Could always do both the extra modifier and the switch. Doing the switch doesn't stop us from ?? or something else.
  • Beautiful world is ? on properties and index signatures always allow reading undefined, not writing.
• Conclusion:
  • Do a flag.
  • Not under --strict.
  • DefinitelyTyped and lib.d.ts
  • --init should include it once the ecosystem catches up.
  • Bike-shed option name offline.

symbol and Template String Signatures

#44512

• Regression in material-ui, literal types in property names.
  • Optimization in picking applicable index signatures.
  • Mostly caught up in perf.
• Allows you to use symbol and templates with placeholders as index signatures.
  • Idea: only allow infinite primitive types in index signatures.
• This PR does allow a union in an index signature.
  • De-sugars into several different index signatures.
  • That's how it's represented internally.
• IndexInfo array upon request.
• Index signatures mostly unrelated, except that number index signatures must be related to string index signatures, and now some number
• You can now apply to multiple index signatures - was true before, but only because number had to be more specific than string.
  • We should intersect the result in those cases. (?)
    • When reading?
    • Seems fishy that you'd get something with more capabilities when index signatures overlap.
  • We distribute over indexing with a union.
• Feels like we don't have a way forward for supporting finite union types in index signatures if you support unions in these index signatures.
  • In those cases, mapped types might be the more appropriate thing to use.