Skip to content
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

Closed
jbondc opened this issue Sep 15, 2015 · 5 comments
Closed

Intersection types - conflicts #4805

jbondc opened this issue Sep 15, 2015 · 5 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@jbondc
Copy link
Contributor

jbondc commented Sep 15, 2015

A story of language its importance in cognition.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 15, 2015

num is an enum type, not the enum value, so on both enumClass and classEnum a has only one declaration, which is a function.

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:

The type A & B has a property P if A has a property P or B has a property P. If A has a property P of type X and B has a property P of type Y, then A & B has a property P of type X & Y.

@mhegazy mhegazy added the Question An issue which isn't directly actionable in code label Sep 15, 2015
@ahejlsberg
Copy link
Member

Regarding order and errors, a key feature of the & type operator is that it can be applied to type parameters. This deeply affects the semantics of the operator, particularly as it relates to ordering and error reporting, as I explain here.

A bit more regarding ordering: With the current rules we can assume A & B is a subtype of (and assignable to) both A and B, even when A and B are type parameters. With "last one wins" we could only assume A & B is a subtype of B (because B might override members of A). That would lead to a number of surprises and inconsistencies.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 16, 2015

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.

@ahejlsberg
Copy link
Member

@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.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 16, 2015

gives a nicer error message.

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.

@mhegazy mhegazy closed this as completed Sep 17, 2015
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

3 participants