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
Ryan and I have had extensive conversations about this problem. In my opinion this should clearly fail since both Dog and Cat are classes. Type safety should ensure that when we demand a class type the thing passed in should be in the inheritance chain. Structural typing shouldn't apply to classes.
There's an argument to be made that this case also shouldn't be supported for interfaces, which I'm also sympathetic to. This similar example proves the problem:
However, if we mark furColor as optional, I think there's a totally valid argument to be made that it should compile and the desired behavior is met, e.g.
interfaceDog{furColor?: string}interfaceCat{}functionwalk(d: Dog): void{}functionpet(c: Cat): void{}constd: Dog={furColor: "brown"};constc: Cat={};walk(c);// no error, good!pet(d);// no error, good!
A similar thing is the ability to assign object literals to class types as long as they have the same members, but currently constructor is not such a required member. So this issue is a prerequisite for #3841
classFoo{constructor(publicprop: string){}staticbar(){}}varfoo=newFoo("5");foo.constructor.bar();// Currently not allowed. Would be allowed if #3841 is implemented.varfoo2: Foo={prop: "5"};// Currently allowedfoo2.constructor.bar();// Currently not allowed. Should continue to not be allowed if #3841 is implemented, which means the assignment itself should be disallowed.
This is an issue that we have talked about on and off over the past years. for this to proceed we will need a proposal for how this fits in the current system, what are the proposed new rules for comparing class types, what impact of a change does this have on existing code (we can help out with part by running the ts internal snapshot of real world code bases).
Activity
zpdDG4gta8XKpMCd commentedon Dec 5, 2015
so what is the take out of what you said? what's the action item?
Arnavion commentedon Dec 6, 2015
A similar thing is the ability to assign object literals to class types as long as they have the same members, but currently
constructoris not such a required member. So this issue is a prerequisite for #3841mhegazy commentedon Dec 8, 2015
This is an issue that we have talked about on and off over the past years. for this to proceed we will need a proposal for how this fits in the current system, what are the proposed new rules for comparing class types, what impact of a change does this have on existing code (we can help out with part by running the ts internal snapshot of real world code bases).
RyanCavanaugh commentedon Jul 17, 2020
I think some day we might revisit class nominality, but we haven't seen any proposals we really like yet