Design Meeting Notes, 9/18/2020

[DanielRosenwasser]

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.

[wycats]

Still stage 3, very bizarre.

As far as I know, public fields have already shipped in all evergreen browsers. Can someone expand on what the conversation in the design meeting was about?

[weswigham]

All major browsers have shipped the feature, without flags (and have done so for awhile at this point) - making it defacto in the language as-is, spec or no, but it hasn't advanced to stage 4 yet (meaning "will be in the next published spec"), for some reason, so we can't even include it in a yearly spec preset yet! ☹️

[Jamesernator]

All major browsers have shipped the feature, without flags (and have done so for awhile at this point) - making it defacto in the language as-is, spec or no, but it hasn't advanced to stage 4 yet (meaning "will be in the next published spec"), for some reason, so we can't even include it in a yearly spec preset yet! ☹️

This is part of the TC39 agenda for this meeting: https://docs.google.com/presentation/d/14ynZtqqlB9mCfK7iYdpwtO6hMV7dv9fVW0Z67PEwGzI/edit#slide=id.p

The TLDR is that they want all class field features (private/public, static/instance, method/field) to be unified into a single class fields proposal, so all class field features will reach stage 4 at once (when implementations are shipping all the features).