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?
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.
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?
Conclusion
no useDefineForClassFields for the time being.
Revisit types: [] in the future if we have better error messages.
Primitives Types in Template Slots
#40598
string,number, andbigintare these infinite types that can go into these template types.string.${string}becomesstringwhich is not incorrect.http://${string}to exist and be reasoned about #40598,stringin a substitution position just sits around, acts kind of like if you usedTwhereT extends string.numbertoo, you'd be able to say "I take numeric strings" (accepting only canonical string representations of those numbers).bigints in these literal types?numberand numeric literal types, then you can only write these things via inference.stringin them tostring.XML Namespaces: What do they do? Do they do anything? Let’s find out!
#37421
"jsx": "react"?--tsc initdefaults#39642
--downlevelIterationis still opt-in.--target es2015?useDefineForClassFieldsfor the time being.types: []in the future if we have better error messages.