-
Notifications
You must be signed in to change notification settings - Fork 110
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
Feature Request: Support intersections of object types #886
Comments
This is a special case of this TODO: tsickle/src/type_translator.ts Line 457 in 74aff76
|
Just making sure I follow, what do you suggest we do in cases like type X = HTMLAnchorElement & {foo: string} ? |
I had assumed to ignore that & keep |
We recently ran into this with some code that used an intersection type for |
No; I no longer have time for this at the moment. |
Same here as on issue #1067 I think. We fundamentally cannot support this properly without support in Closure Compiler. Intersection types aren't just syntactical sugar for the expansion of their fields, even in a language based on structural types. For an example, consider a recursive intersection type:
There are similar problems with generic type parameters and so on. I suspect it'll be very brittle to try and scope it down to a whitelist of supported cases, so I think accepting the loss of precision here is best we can do. We could consider being more aggressive in the case of externs, where not emitting a type may actually break program optimization (basically @engelsdamien's case in issue #1067). We could error out in that case so that there's at least no silent failure. OTOH, we'd need to carefully assess the impact of that. I suspect this might break a lot of existing .d.ts files. |
TypeScript code: (this is a minimal example; I have a complex usecase involving builders in which I don't think there are alternatives)
Actual Closure Code:
Expected Closure Code: (what you get if you replace
}&{
with,
)The text was updated successfully, but these errors were encountered: