Intersection types - conflicts #4805

Activity

1. mhegazy commented on Sep 15, 2015

   

   Mohamed Hegazy (mhegazy)

   on Sep 15, 2015

   Contributor

   More actions

   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.
2. Mohamed Hegazy (mhegazy)

   added

   QuestionAn issue which isn't directly actionable in codeAn issue which isn't directly actionable in code

   on Sep 15, 2015
3. ahejlsberg commented on Sep 15, 2015

   

   Anders Hejlsberg (ahejlsberg)

   on Sep 15, 2015

   Member

   More actions

   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.
4. mhegazy commented on Sep 16, 2015

   

   Mohamed Hegazy (mhegazy)

   on Sep 16, 2015

   Contributor

   More actions

   Like Anders Hejlsberg (@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.
5. ahejlsberg commented on Sep 16, 2015

   

   Anders Hejlsberg (ahejlsberg)

   on Sep 16, 2015

   Member

   More actions

   Jon (@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.
6. mhegazy commented on Sep 16, 2015

   

   Mohamed Hegazy (mhegazy)

   on Sep 16, 2015

   Contributor

   More actions

   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.
7. Mohamed Hegazy (mhegazy)

   closed this as completedon Sep 17, 2015
8. microsoft

   locked and limited conversation to collaborators on Jun 19, 2018