You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When incorrectly but explicitly implementing an interface using implements, an error should only be shown for the incorrectly implementing class, but not at every location that casts the class to the interface (which is the current behavior).
interfaceIFoo{baz: string;bla: string;}classFooimplementsIFoo{// Only show the error herebaz='baz';}functiontest(foo: IFoo){}test(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error heretest(newFoo());// Don't show the error here
Motivation 1: implements as post-condition
When a function indicates that it returns a string, but the implementation returns a number instead, the error already is only shown for the function and not at every usage:
functiontest(): string{return1;// Error is shown here}letx: string=test();// Not here
As expected, test(): string indicates a publicly facing contract that test() is guaranteed to return a string. It is a local implementation detail that it does not.
Analogous, if Foo publicly states that it implements IFoo, every consumer should also be allowed to assume that Foo indeed implements IFoo.
Incorrect implementations are implementation details of the class and should not leak into usages.
Motivation 2: A Use-case
In the VS Code codebase, there are many interfaces that are implemented many times.
In some cases, the implementations are also used many times and very often passed to functions that expect the interface.
When changing/extending such an interface, hundreds of errors are reported: At every location that casts the class to the interface and at every class declaration that states it is implementing the interface.
This makes it very difficult to find all the locations where the interface is implemented incorrectly.
The text was updated successfully, but these errors were encountered:
Description
Example
When incorrectly but explicitly implementing an interface using
implements
, an error should only be shown for the incorrectly implementing class, but not at every location that casts the class to the interface (which is the current behavior).Motivation 1:
implements
as post-conditionWhen a function indicates that it returns a string, but the implementation returns a number instead, the error already is only shown for the function and not at every usage:
As expected,
test(): string
indicates a publicly facing contract thattest()
is guaranteed to return astring
. It is a local implementation detail that it does not.Analogous, if
Foo
publicly states that it implementsIFoo
, every consumer should also be allowed to assume thatFoo
indeed implementsIFoo
.Incorrect implementations are implementation details of the class and should not leak into usages.
Motivation 2: A Use-case
In the VS Code codebase, there are many interfaces that are implemented many times.
In some cases, the implementations are also used many times and very often passed to functions that expect the interface.
When changing/extending such an interface, hundreds of errors are reported: At every location that casts the class to the interface and at every class declaration that states it is implementing the interface.
This makes it very difficult to find all the locations where the interface is implemented incorrectly.
The text was updated successfully, but these errors were encountered: