Skip to content
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

Allow inheritance from intersections #14075

Closed
sandersn opened this issue Feb 14, 2017 · 4 comments
Closed

Allow inheritance from intersections #14075

sandersn opened this issue Feb 14, 2017 · 4 comments
Assignees
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue

Comments

@sandersn
Copy link
Member

Based on #14017, when exporting a class that extends from a mixin, the emitted type contains an intersection. Inheriting from an intersection is not allowed, even though it should be.

Note that inheriting from a type alias of an intersection already works:

// A *self-contained* demonstration of the problem follows...
class A { a = 1 } 
class B { b = 2 }
type Both = A & B
class C extends A & B { } // error
class D extends Both { } // ok

Expected behavior:
No error for C or D.

Actual behavior:
Error for C.

@ahejlsberg
Copy link
Member

You're confusing types and expressions in your example. The extends clause of a class requires an expression, not a type, so C and D are both errors. The right way to write the example is

class A { a = 1 } 
class B { b = 2 }
declare const Both: new () => A & B;
class D extends Both { }

This of course omits the details of how A and B are actually intersected.

The declaration file emitter currently depends on the fact that a class declares both a type and a value. It actually emits the extends clause as a type, even though a value is required in that position. We've gotten away with it so far because classes typically inherit from entities that share the same name for a type and a value, but that's no longer the case with mixins.

@mhegazy
Copy link
Contributor

mhegazy commented Feb 15, 2017

Allowing a type in an ambient declaration should be fine though.

@ahejlsberg
Copy link
Member

Not sure how that would work. First, it would be ambiguous how to parse it. Second, we require an expression of a constructor type, not an instance type, so you couldn't just write A & B as those are instance types.

@mhegazy mhegazy added the Bug A bug in TypeScript label Feb 22, 2017
@mhegazy mhegazy added this to the TypeScript 2.3 milestone Feb 22, 2017
@mhegazy
Copy link
Contributor

mhegazy commented Feb 22, 2017

Either we allow inheriting from types in ambient declarations, or we need to write a declare const before a class with a type that has no name.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue
Projects
None yet
Development

No branches or pull requests

3 participants