False error reported when computing LUB of sealed class involving mixins

[Mike278]

$ dart --version
Dart SDK version: 3.6.0 (stable) (Thu Dec 5 07:46:24 2024 -0800) on "macos_x64"

In the following snippet, VSCode reports the error at the specified location.

mixin Equatable {}

sealed class S {}
class A extends S with Equatable {}
class B extends S with Equatable {}

S f1(bool b) {
  return b ? A() : B();
     //  ^^^^^^^^^^^^^ A value of type 'Object' can't be returned from the function 'f1' because it has a return type of 'S'
}

// control flow analysis can figure it out, no error here:
S f2(bool b) {
  S s;
  if (b) s = A();
  else s = B();
  return s;
}

However dart analyze finds no issues:

$ dart analyze lib/lub.dart 
Analyzing lub.dart...              0.7s
No issues found!

Removing the with Equatable clauses fixes the warning.

Interestingly, adding a top type to S also seems to fix the warning:

mixin Equatable {}

sealed class _Top {}
sealed class S extends _Top {}
class A extends S with Equatable {}
class B extends S with Equatable {}

S f1(bool b) {
  return b ? A() : B();
}
S f2(bool b) {
  S s;
  if (b) s = A();
  else s = B();
  return s;
}

[lrhn]

This error is working as designed.
The upper bound operation tries to find a unique most specified common superinterface.
In this case, both S and Equatable are superinterfaces.

It then tries to use the "depth" of the interface (length of the the shortest immdiate-superinterface chain from it to Object) to decide which is "more specific". That also fails here since both S and Equatable has depth 1. Then it gives up finding a solution with depth 1, and falls back to depth zero, aka. Object.

That's why adding a Top supertype to S, but not to Equatable, makes a difference. It gives S a depth of 2 instead, so it beats Equatable.

If the analyzer doesn't find an error, it might be because it treats S with Equatable as the same class as the superclass of both A and B. That class has depth 2, and it's a superinterface of both A and B,
(Or because @stereotype441 made the ?/: operator less oblivious to the context, it has a context type of S here, so there is no need to up-cast to Object first, and then fail to be assignable to S, when both sides are already assignable to S.)

If the front-end treats A's superclass as a different class than B's superclass, as different mixin applications of Equatable to S, then neither is a shared superinterface.

It used to be that each mixin application was specified as being a unique class. I don't remember if that was softened to allow compiles to treat mixin application of the same mixin to the same class as introducing the same mixin application class in multiple places.

(The "control flow can figure it out" isn't really true, it just accepts that both are assignable to S, but does not need to find a common supertype for A and B.)

[eernstg]

The error used to be correct, and I agree on all the superinterface explorations explaining how.

However, with 'inference-update-3' (enabled in 3.4.0), the type of a conditional expression is computed in such a way that the context type is used as a hint to resolve ambiguities like this. Here is the canonical example:

class A {}

class B1 implements A {}

class B2 implements A {}

class C1 implements B1, B2 {}

class C2 implements B1, B2 {}

B1 test(bool b, C1 c1, C2 c2) => b ? c1 : c2;

main() {
  print('feature enabled');
}

In this case there is no way a computation of the type of b ? c1 : c2 in isolation could choose B1 over B2 or vice versa, because all subtype relationships are mirrored in the ...1 and the ...2 declarations. So we must use the context type (that is, the return type B1) in order to make the example compile without errors.

The feature 'inference-update-3' does exactly this.

The example here has a similar structure.

Also, a test run of this example in DartPad (any channel) succeeds, that is, the error message A value of type 'Object' can't be returned from the function 'f1' because it has a return type of 'S' is not reported by the analyzer nor by the CFE.

It looks like something forced the language version to be lower than 3.4.0 in the case where the error was reported, and current tools do not behave incorrectly (that is, there's no error). Perhaps VScode used an older tool chain?

[eernstg]

@keertip, I think the label 'type-bug' can be removed, so I'll do that. Please restore it if you disagree.

[Mike278]

It looks like something forced the language version to be lower than 3.4.0 in the case where the error was reported

Ah, this checks out. The sdk version in my pubspec.yaml file was 3.3.4, but the sdk version in my (gitignored) pubspec.lock file was 3.6.0. After changing both to 3.6.0, everything agrees that no error should be reported. This is just a personal side project so I haven't really paid attention to maintaining the environment.

To make this slightly more confusing, in the real codebase I was actually still experiencing the same error in the original report, but now I can see it's for a slightly different reason. A more accurate reproduction is:

void main() {
  final x = DateTime.now().millisecondsSinceEpoch > 0 ? A() : B();
  foo(x);
  //  ^ The argument type 'Object' can't be assigned to the parameter type 'S'. 
}

void foo(S s) {}

mixin Equatable {}
sealed class S {}
class A extends S with Equatable {}
class B extends S with Equatable {}

So instead of having a context type from the S f1(bool b) { as a hint, the void foo(S s) { doesn't propagate a hint back up through foo(x) to ? A() : B().

Ironically, the side project in question is playing around with bidirectional type inference systems like Hindley-Milner 😄. The latest few commits show the original code.

So the main issue was having a lower sdk version in pubspec.yaml compared to the version in the .lock file and the actual version installed, and what that meant for different tools. Unless you think there's anything worth tracking there, feel free to close.

[eernstg]

@jonasfj, do you see any opportunities for providing improved feedback here? For example, do you think it would be helpful for dart pub get or a similar command to report on version mismatches like this? I guess dart pub get would just eliminate some of these discrepancies anyway, but it might be useful for a tool chain with most-recent language version V to report on a pubspec.yaml where the SDK range doesn't include V, or something like that.

[eernstg]

I adjusted the labeling to reflect the fact that this is about version mismatches (in places like pubspec.yaml and pubspec.lock), not about static analysis of a program.