Primitives Types in Template Slots

#40598

type Protocol<T extends string, U extends string> =
    `${string}://${U}`;

• string, number, and bigint are these infinite types that can go into these template types.
  • Whenever you end up with one of these top-types, they become string.
    • It's not expected behavior.
  • You can stop people from writing them statically, but they can always end up in template types via instantiation.
• Today: ${string} becomes string which is not incorrect.
• In Allow pattern literal types like http://${string} to exist and be reasoned about #40598, string in a substitution position just sits around, acts kind of like if you used T where T extends string.
• If you did this for number too, you'd be able to say "I take numeric strings" (accepting only canonical string representations of those numbers).
• Earlier discussions implied that these strings need to be "round-trippable"
  • Means if you turn it into a number, then back to a string, the strings match.
• Why do we want to allow coercions in the type system?
  • There are no coercions that don't exist elsewhere?
• We allow bigints in these literal types?
  • Yes, that's allowed.
• Maybe you should have to convert explicitly?
• If you don't allow number and numeric literal types, then you can only write these things via inference.
  • See convo at Bug: (Any) string is assignable to numeric templated literal type #40538
• Conclusion: assume bigint and number will be allowed, don't absorb templates with string in them to string.
  • Take discussion of allowing other primitive types on a different convo

XML Namespaces: What do they do? Do they do anything? Let’s find out!

#37421

• XML has namespaces
• JSX says it supports namespaces
• We said we'd be open to a PR, but there is still no emit (nor type-checking!) behavior.
• People keep asking for differing behavior, but Babel's behavior is to just look this up as a string with a colon inside of it.
• Doesn't work with the usual target library.
• Don't call it XML namespaces/XML namespace prefixes, nobody actually understands how XML namespaces works.
  • What is it called?
  • Colons permitted in lowercase JSX names.
• Should this be allowed in "jsx": "react"?
  • Again, React doesn't understand, so it might crash or just not work.
  • Well it's just a string, and the components don't declare those property names.
  • So you'll usually get a static error too.
• Conclusion: Approved for 4.2, contingent on no API breaking changes.

--tsc init defaults

#39642

• Enable "useDefineForClassFields" in tsc --init #39311 (comment)
  • Emit's not great unless you have ESNext emit.
  • 4.0 has the errors anyway.
  • Still stage 3, very bizarre.
• We don't always emit 100% spec compliant anyway - --downlevelIteration is still opt-in.
  • The reason we don't want the defaults to include this is the same as the reason we don't
• Should we set '"types": []' for 'tsc init'? #39354
  • Trading one footgun for another.
  • Let's revisit if the error messages can first be switched out.
• --target es2015?
  • Out of time
• Conclusion
  • no useDefineForClassFields for the time being.
  • Revisit types: [] in the future if we have better error messages.