3 ms·
AFAIK, this is actually happening with decorators, which have changed a lot in how they're defined (the latest I can find is the actual spec changes: https://gi
by spankalee 10y ago
AFAIK, this is actually happening with decorators, which have changed a lot in how they're defined (the latest I can find is the actual spec changes: https://github.com/tc39/proposal-decorators/commit/c32ea181569668a6c1ef212c1a85071e2bf53466#diff-3540caefa502006d8a33cb1385720803R19193 https://github.com/tc39/proposal-decorators/commit/c32ea1815...)
Even so, I've been pretty impressed with the TypeScript teams ability to manage this kind of change an uncertainty and keep up with and move closer to standard JavaScript where they have been differences.
Specifically regarding the `!` operator* , to convert to standard JavaScript just remove the `!` operator, like you would remove a cast or type annotation. It's still within the TypeScript spirit to me.
* I personally would have rather seen it either be a type of cast (maybe `<!>strs.map(...);`), or add a null-safe property accessor: `strs?.map(...)` which doesn't assert that `strs` is non-null, but makes the expression null-safe, returning null if `strs` is null.
- TheCoreh 10y agoThat null-safe property accessor (`?`) is being discussed for ES, and it's reasonable to assume that it will ship eventually. They wouldn't add that and risk having different semantics.