-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Type-directed emit breaks language design goals. Is it worth it? #6007
Comments
I agree that this goes against the idea of type-directed emit, and I think that's been a great guiding principle, but I'm not entirely sure what a better approach would be. Do you have any suggestions for how to continue with the current approach? @mhegazy and @rbuckton, we were discussing this the other day. |
For what it's worth this is how I would propose to handle Gist of original comment is here. |
If we must accept that type-directed emit is here to stay, could we at least fix the inconsistency described in #6027? If that was done, then the type-directed emit of async functions would at least be in harmony with the expected behaviour of type annotations, rather than in conflict with it. |
Why does TypeScript need to do this at at? ES7 async functions do not support returning custom Promise types - they always return ES6 Promise instances, even if For ES3/ES5 there is no ES6 Promise available so there must be a way to polyfill |
Thanks team and especially @rbuckton for addressing this for ES6+. With #6631 merged, async functions are more ES7-compliant and return type annotations no longer affect the emitted JavaScript with target >= ES6. I'd like this issue to remain open however to discuss async function support for ES3/ES5 (via downlevelling), which is currently slated for v2.0. It seems it may still use return type annotations to emit different code (eg see comments here and here). To me this seems unnecessary. As a web developer targeting older browsers, It would be great to be able to write with
In particular I don't wan't to have to add a type annotation to every async function telling it what kind of promise to return. Standard practice is to do polyfilling once at startup, not at every function site. |
Bumping this issue again, since 2.1RC just came out and is the first release with downlevel async/await (congrats on another great batch of features!). Better to annotate each async function, or just polyfill Promise?A few weeks ago I brought up the quirks of annotating async functions (here and here). @RyanCavanaugh responded:
However I noticed the 2.1RC blog post makes no mention of this 'huge' feature when demonstrating how to use async/await is ES3/5 environments. Rather, the blog post describes using a runtime So to renew the discussion, may I ask again are non-erasable, non-structural return type annotations really a worthwhile exception in the type system? They don't seem to have been promoted anywhere. As the blog post shows, they aren't even necessary for using async/await in ES3/5. And they have several downsides. Downsides to type-directed emit of async function annotationsImportantly, there are downsides to using return type annotations for type-directed emit:
Future TS Versions?So is there any chance of a future version having async function return type annotations that are consistent with the rest of the language? The breaking change is straightforward for users to fix, and I suspect most users are not even aware of the current behaviour. The scenario that type-directed emit specifically caters for is when a project has async functions that must produce several different implementations of |
Polyfilled Promises are rapidly vanishing from the earth; I think we're satisfied with the design as-is here unless there are more concrete manifestations down the line (please raise those as new issues if so) |
Project A:
Project B:
These two projects differ only by a single type annotation, but they produce different JavaScript code with different runtime behaviour.
(Compiled with v1.7.3 with
target=ES6, module=commonjs, noEmitHelpers=true
).(Note elison bug #6003 is also visible here but not the subject of this issue.)
Bug or by design?
I understand this is by design (sorry I can't find a better ref).
However I strongly feel this should be considered a bug, because having a "fully erasable, structural type system" is a core design principle of TypeScript (quote is from the design goals page).
If this is tagged as 'by design', could we please get some sort of statement from the team to clarify where TypeScript now stands on the "fully erasable type system" goal and the "[don't] emit different code based on the results of the type system" non-goal?
The text was updated successfully, but these errors were encountered: