-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ES6 should be valid TypeScript #2606
Comments
You'll find with your example that although the compiler says the code has a type error, it will still emit valid ES, e.g. as ES5:
TS has three levels of correctness. If the input code is syntactically correct (prior to type checking) then it can generate ES output, and it is "valid" TS. At this first level, TS is a superset of ES, in that the set of valid TS programs is larger than the set of valid ES programs (because it includes all the valid ES programs plus those with type annotations). The second level is type-correctness, which is what your error is complaining about. At this level, TS can act as a subset of ES: some valid ES programs, such as your example, are not type-correct TS programs. So if you want your program to jump both these hurdles, then is TS is not a simple superset of ES. If it was, then there would be no value at all in having a static type system, as it would accept every ES program without errors, and so add no value over ordinary ES. So this is most definitely a feature, not a 'bug'. Note that you can effectively eradicate level 1 by using the An alternative approach that a compiler could adopt would be to infer from your constructor code that the class But TS takes the approach of requiring you to declare the shape of your classes and modules. This is important because it means that you will know when you are making a change that will affect callers, i.e. when you are changing the interfaces between separated concerns in your code:
Note I've also added an explicit statement of the type of the parameter to the constructor. This satisfies the third level of correctness: |
I'll note that we have had requests for better support for this particular pattern. I can't find the related issues right now (that's happening more frequently these days...) |
I just jumped between marking this as a duplicate and turning this into a meta-issue, but I don't think we can turn something this broad into a meta issue. |
I think that in general, the cost of the solution to this on the user end (declaring a member) is not high enough to add complexity to the type system, which itself is incurred on the user as well. |
Duplicate of #766 |
Thank you all for the comprehensive clarification. That was quick :-) I agree with @sccolbert (#2393):
I think that a big part of the success of less/scss is due to the full compatibility with css. Just start with css syntax and gradually learn/use more and more superset features. The same applies to Babel as well. I can just add Babel to my build pipeline without rewriting my exiting code. And I think the same should apply to TypeScript. I really like how TypeScript becomes more compatible with ES6 with 1.5. But with issues like this, the ES6 circle (from the ngConf slide) will never be completely inside the TypeScript circle and therefore TypeScript wouldn't be a superset of JavaScript but a own language. (Sorry, sounds a little bit harsh) @DanielRosenwasser: I think, it is not just about the cost of declaring a member in this case but the ES6 compatibility as a whole. @basarat: I don't understand how #766 is related with ES6 compatibility. Isn't this issue rather a duplicate of #2393? I am interested on what we should do with issues like these. What about tagging issues which are related to ES6 incompatibly? Or creating a ES6 incompatibility list? |
That's what I assumed you were asking - my comment above is an attempt to answer that wider question. Slides like the ngConf one you mentioned (concentric circles) are not accurate depictions of compatibility. They are depictions of feature sets. TS is only a compatibility-superset of ES if you ignore static type checking. |
This can be eased with tooling though: https://github.com/TypeStrong/atom-typescript#quick-fix |
@basarat this is awesome 🏆 💯 |
@mhegazy your language service is awesome! 🌹 |
💯 Very cool @basarat ❗ |
Since TypeScript is a superset of JavaScript it should be possible to compile ES6 code without errors.
This valid ES6 snippets throws the following error:
Is this a bug or a 'feature'?
The text was updated successfully, but these errors were encountered: