Reputation: 686
Let say we have this code:
class MyEvent {
timestamp:number;
}
class AEvent extends MyEvent{
x:number;
y:number;
}
class BEvent extends MyEvent{
key:string;
}
var fn:(event:MyEvent)=>void;
function AE(event:AEvent){
let x = event.x; //Ok, but BEvent hasn't 'x' property.
}
fn = AE;
fn(new BEvent());
Typescript doesn't inform about error. For typescript it is a valid code. I have tried it in typescript playground. (1.8 version)
How do I enforce typescript to forbid it?
For example, in C++
class Base {
public:
int timestamp;
};
class B: public Base {
public:
char key;
};
class A: public Base {
public:
int x;
int y;
};
void fA(A *ptr) {}
void (*fn)(Base *ptr);
int main()
{
A *a = new A();
B *b = new B();
fn = fA; //error: invalid conversion from 'void (*)(A*)' to 'void (*)(Base*)'
fn(b);
}
Upvotes: 0
Views: 71
Reputation: 1189
The function parameters are bivariant to allow common javascript patterns even if some runtime error can occur in some rare case.
According to type compatibility handbook :
When comparing the types of function parameters, assignment succeeds if either the source parameter is assignable to the target parameter, or vice versa. This is unsound because a caller might end up being given a function that takes a more specialized type, but invokes the function with a less specialized type. In practice, this sort of error is rare, and allowing this enables many common JavaScript patterns.
Why are function parameters bivariant?
In summary, in the TypeScript type system, the question of whether a more-specific-type-accepting function should be assignable to a function accepting a less-specific type provides a prerequisite answer to whether an array of that more specific type should be assignable to an array of a less specific type. Having the latter not be the case would not be an acceptable type system in the vast majority of cases, so we have to take a correctness trade-off for the specific case of function argument types.
Upvotes: 2