Home > Enterprise >  Is it possible that TypeScript syntax conflict with EMCAScript?
Is it possible that TypeScript syntax conflict with EMCAScript?

Time:05-25

Typescript used to say that "TypeScript is a typed superset of JavaScript."

But if ECMAScript add some new syntax, which is conflict with the existing syntax of TypeScript, the 'superset' relationship between TypeScript and JavaScript will broken.

Will this happen?


eg: TypesScript has Parameter Decorators syntax, if ECMASript add Parameter Decorators syntax too in future, but the decorator function has different arguments.

CodePudding user response:

Will this happen?

No one can predict the future, but with regard to decorators, note this from the TypeScript decorators documentation:

NOTE: Decorators are an experimental feature that may change in future releases.

In fact, we know that TypeScript's current decorators will not be compatible with JavaScript's own if/when they're finalized: TypeScript's decorators are based on an earlier version of the proposal that failed to get consensus from TC39 and has since been extensively reworked (at least twice). But TypeScript already has the experimentalDecorators flag to handle that. Eventually, if you don't have that flag set but you use decorators syntax, you'll be using JavaScript's own decorators syntax. If you do have the flag set, you're using TypeScript's current form of decorators.

But that (or other examples of minor incompatibility¹) don't necessarily mean that the sense of the saying "TypeScript is a typed superset of JavaScript" is wrong, just that the real picture is more complicated and nuanced than that overarching concept and goal.


¹ I don't recall the specific example, but IIRC it involves supplying explicit type arguments when calling a function (or is it the old angle-bracket form of type assertion?) conflicting in some very limited edge cases with the less-than operator <.

  • Related