-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Intersection types - conflicts #4805
Comments
i think what you mean is: type enumClass = typeof num & cls;
type classEnum = cls & typeof num;
let ec: enumClass;
ec.a; // num & a() => void
let ce: classEnum;
ce.a; // a() => void & num this is described in #3622:
|
Regarding order and errors, a key feature of the A bit more regarding ordering: With the current rules we can assume |
Like @ahejlsberg explained earlier intersection tupes do not have a concept of a conflict; if the two types have a property with the same name, the intersection of the will have a property with the intersection of the property type in both. The rational is we have no way to resolve these conflicts correctelly, nor s good place to show the error. I think what you are looking for is traits or mixin support for classes; if and when this is supported, we should be able to enforce a resolution policy and flag conflicts. We shied away from these as the Emmasctipt committee showed interest in pursuing it and we do not want to conflict with the standard. |
@jbondc Type instantiation is aggressively deferred (i.e. it only happens if and when it needs to) and it is not possible to consistently report errors during instantiation (because it may never happen). We also can't eagerly instantiate types because we quickly end up in infinite instatation chains when types reference themselves. |
We really can not do that. by the time you discover the conflict, you are way deep in instantiating a type, and there is not much meaningful information you can give to the user. this is one of the main reasons intersection types work the way they do. |
A story of language its importance in cognition.
The text was updated successfully, but these errors were encountered: