Inferred type too general?

[modulovalue]

Hello,

Could it be a bug that the type of listA isn't List<Base<All>> but List<Object>?

My expectation was that the type of listA would be the most specific type possible i.e. List<Base<All>> in this case and not List<Object>.

void main() {
  const listA = [Err(), Leaf()];
  print(listA.runtimeType); // prints List<Object>
  const listB = <Base<All>>[Err(), Leaf()];
  print(listB.runtimeType); // prints List<Base<All>>
}

abstract class Base<H> {}

class Err implements Base<All> {
  const Err();
}

class Leaf implements Base<Valid> {
  const Leaf();
}

abstract class All {}

abstract class Valid implements All {}

[eernstg]

In the case where we're computing the least upper bound of Err and Leaf, the least upper bound algorithm in Dart uses a rule, let's call it R_old, which has been part of the language since Dart 1. In general, R_old is used to find the least upper bound of two class types that aren't generic instantiations of the same class.

The rule R_old is specified here.

This rule is rather simplistic and it yields upper bounds that are considerably less tight than they could be. For example, the least upper bound of Err and Leaf turns out to be Object rather than Base<All>. The basic idea is that it selects the most special shared superinterface of the operands as a whole, and it never applies the least upper bound algorithm on subexpressions of those types. This means that Dart avoids some termination issues that had come up in the context of Java. Moreover, the rule R_old has also been kept unchanged all the time because it is a seriously breaking change to introduce a different rule.

But it is certainly a known issue that the least upper bound algorithm delivers suboptimal results in this particular case. See least-upper-bound Proposals about improvements of the LUB algorithm for more discussions about improving the least upper bounds algorithm.

[modulovalue]

Note: this issue is relevant to #844 and spebbe/dartz#32. Anyone trying to do something similar will eventually come across this.

[modulovalue]

I'm going to close this issue because I don't think that it's likely that many people would benefit from focusing on this issue alone.

I think that a fresh discussion around #844 (and, more broadly, use cases for phantom types, e.g., #2865 & #3273) would be needed to make discussing this particular issue worthwhile.