Suggestion: Allow interfaces to "implement" (vs extend) other interfaces
See original GitHub issueSearch Terms
interface, implements
Suggestion
Allow declaring that an interface “implements” another interface or interfaces, which means the compiler checks conformance, but unlike the “extends” clause, no members are inherited:
interface Foo {
foo(): void;
}
interface Bar implements Foo {
foo(): void; // must be present to satisfy type-checker
bar(): void;
}
Use Cases
It is very common for one interface to be an “extension” of another, but the “extends” keyword is not a universal way to make this fact explicit in code. Because of structural typing, the fact that one interface is assignable to another is true with or without “extends,” so you might say the “extends” keyword serves primarily to inherit members, and secondarily to document and enforce the relationship between the two types. Inheriting members comes with a readability trade-off and is not always desirable, so it would be useful to be able to document and enforce the relationship between two interfaces without inheriting members.
Consider code such as:
import { GestureHandler } from './GestureHandler'
import { DropTarget } from './DropTarget'
export interface DragAndDropHandler extends GestureHandler {
updateDropTarget(dropTarget: DropTaget): void;
}
function createDragAndDropHandler(/*...*/): DragAndDropHandler {
//...
}
While this code is not bad, it is notable that DragAndDropHandler omits some of its members simply because it has a relationship with GestureHandler. What are those members? What if I would like to declare them explicitly, just as I would if GestureHandler didn’t exist, or if DragAndDropHandler were a class that implemented GestureHandler? I could write them in, but the compiler won’t check that I have included all of them. I could omit extends GestureHandler
, but then the type-checking will happen where DragAndDropHandler is used as a GestureHandler, not where it is defined.
What I really want to do is be explicit about — and have the compiler check — that I am specifying all members of this interface, and also that it conforms to GestureHandler.
I would like to be able to write:
export interface DragAndDropHandler implements GestureHandler {
updateDropTarget(dropTarget: DropTaget): void;
move(gestureInfo: GestureInfo): void
finish(gestureInfo: GestureInfo, success: boolean): void
}
Examples
See above
Checklist
My suggestion meets these guidelines:
- This wouldn’t be a breaking change in existing TypeScript / JavaScript code
- This wouldn’t change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn’t a runtime feature (e.g. new expression-level syntax)
Issue Analytics
- State:
- Created 5 years ago
- Reactions:49
- Comments:27 (8 by maintainers)
Top GitHub Comments
@ArmorDarks I think you can achieve the effect you want without any changes to typescript. You can have a type alias as the extends clause. The type alias can check if the currently declared interface extends the wanted interface in its type parameters but the actual result of this type alias will never add anything to the interface (it will be
{}
).Usually unused type parameters are a bad idea, but I think we can at least rely on the fact that the type parameter constrains will be checked on instantiation of the type alias even if they are not used afterwards (although I am ready to be contradicted on that by anyone with more insight into this).
The disadvantage of this is that you have to be aware that this exists and of its semantics, but ultimately using
implements
would have the same drawbacks and theimplements
solution might actually confuse a lot of people when they mistakenly useimplements
and get different results then they would expect.Maybe this is a better readable approach to reach the behavior: https://www.codegrepper.com/code-examples/typescript/typescript+override+interface+property
Based on the example above I made this, a lot readable imo despite it don’t use
interfaces
buttypes