Type parameter is lost when using a typedef for a mixin

[navaronbracke]

I have a mixin that uses some generics.
Since the effective type name of the mixin got quite long in the usage of said mixin, I put it in a typedef.
When I then consumed a method from the mixin, I noticed that a generic type came out as dynamic, even though the effective type was specified in the generic type bound in the with clause / typedef.

Strangely enough, when not using a typedef and just using the mixin type directly the type was correctly inferred and I had no dynamic anymore.

Steps to reproduce

1. dart create myapp (a console app is fine)
2. add the files from the code sample under the /lib folder
3. hover over the method in case 1, works as expected (typing is inferred correctly)
4. replace case 1 with case 2
5. hover over the method again
6. the IDE tooltip displays dynamic even though the type that was specified in the typedef should have been inferred

Code sample

my_mixin.dart

import 'package:myapp/my_model.dart';
import 'package:myapp/widgets.dart';

mixin MyMixin<T, W extends StatefulWidget> on State<W> {
  void listenToEvents(Stream<MyModel<T>> stream) {
    stream.listen((event) {});
  }
}

my_model.dart

class MyModel<T> {
  MyModel(this.data);

  final T data;
}

my_widget.dart

import 'package:myapp/my_mixin.dart';
import 'package:myapp/my_model.dart';
import 'package:myapp/widgets.dart';

typedef MyMixinTypedef = MyMixin<String, MyWidget>;

class MyWidget extends StatefulWidget {}

// TODO: hover over `listenToEvents` and observe the tooltip

// Case 1: without additional typedef
// produces `void listenToEvents(Stream<MyModel<String>> stream)`

class MyWidgetState extends State<MyWidget> with MyMixin<String, MyWidget> {
  void doSomething() {
    listenToEvents(Stream.value(MyModel('foo')));
  }
}


// Case 2: with typedef for the mixin
// produces `void listenToEvents(Stream<MyModel<dynamic>> stream)`

/*
class MyWidgetState extends State<MyWidget> with MyMixinTypedef {
  void doSomething() {
    listenToEvents(Stream.value(MyModel('foo')));
  }
}*/

widgets.dart

abstract class Widget {}

abstract class StatefulWidget extends Widget {}

abstract class State<T extends StatefulWidget> {}

Dart SDK version: 2.17.1 (stable) (Tue May 17 17:58:21 2022 +0000) on "macos_x64"
Dart Code version: v3.42.1
VSCode version: 1.67.2 (Universal)

[johnniwinther]

The CFE generates the same output in both cases. Given that this shows up in the tooltip, it might be a problem in the analyzer.

cc @scheglov

[scheglov]

Thank you for a good reproduction scenario.

The issue in the analyzer is that we ignore the fact that the mixin is referenced via typedef, and attempt to infer type parameters of the mixin once again.

While this would be easy to fix in this case, when we have already provided all type arguments for the mixin, this raises a question whether we need to perform type inference on partially instantiated mixins. The code below could theoretically produce M<String, int>:

mixin M<T, U> on S<T> {
  void foo() {
    print(T);
    print(U);
  }
}

typedef M2<T> = M<T, int>;

class S<T2> {}

class X extends S<String> with M2 {}

main() {
  X().foo();
}

...but CFE instead uses M<dynamic, int>, so probably does not do any inference in this case.

bin/test4.dart:12:7: Error: 'S with M2' can't implement both 'S<String>' and 'S<dynamic>'
 - 'S' is from 'bin/test4.dart'.
class X extends S<String> with M2 {}
      ^
bin/test4.dart:12:7: Error: 'S<String>' doesn't implement 'S<dynamic>' so it can't be used with 'M<dynamic, int>'.
 - 'S' is from 'bin/test4.dart'.
 - 'M' is from 'bin/test4.dart'.
class X extends S<String> with M2 {}
      ^

@eernstg @stereotype441 any ideas from the language team?

[lrhn]

While this would be easy to fix in this case, when we have already provided all type arguments for the mixin, this raises a question whether we need to perform type inference on partially instantiated mixins.

I think you should perform type inference on partially instantiated types accessed through aliases.

Aliases should, as far as possible, be transparent and act as their expansion.
This is a place where it's not trivial to say what that even means.

Generally, I think it's reasonable to treat inference on an alias for an interface/class/mixin type as if the alias was a proper declaration with the thing it aliases as a super-interface.

So,

class C<S, T> {
  C(S a, T b);
}

typedef D<S> = C<S, num>;

var d = D("a", 1); // ?

would do type inference "somewhat like" if D was really:

class _D<S> extends C<S, num> {
  _D(super,a, super.b);
}

and then find the type of it "at C".

In that case, inference of var d = _D("a", 1); should infer D<String> which implements C<String, num>, which is then the type that the type alias application var d = D("a", 1); should also deduce.

For mixin application, I think inference would be able to do something similar, so

mixin M<T, U> on S<T> {
  void foo() {
    print(T);
    print(U);
  }
}

typedef M2<T> = M<T, int>;

class S<T2> {}

class X extends S<String> with M2 {}

would act like M2 was

mixin _M2<T> on S<T> implements M<T, int> {
  void foo() {...}
}

and do inference on the mixin application S<String> with _M2, find its type "at M (M<String, int>) and then use that as the actual parameters to the expanded type alias, becoming S<String> with M<String, int>.

That's what I would expect. I don't know what we actually do (but apparently not it).
I also don't know what we have specified, if anything, so this is just, like, my opinion.

(In the constructor tear-off specification, we introduced a "corresponding constructor" for type aliases that didn't just pass type arguments straight through, but those which did, "proper renames", were treated specially. Here, any alias which isn't linear in the type parameters cannot be expanded before inference, so may need this approach of treating as if it was a declaration itself, and maybe we should just do it for any non-proper-rename alias.)

[johnniwinther]

cc @chloestefantsova

[eernstg]

I would expect mixin inference to need an update such that type aliased mixins are taken into account.

With that update, the mixin inference for a raw type alias Malias denoting a mixin M should take place such that the outcome is an actual type argument list to Malias, yielding Malias<T1, .. Tk>, which satisfies the constraint that the enclosing class does not have an error of the form 'implements the superinterface S with multiple different actual type argument lists'. This kind of type inference would rely on type information from the superclass, but not from any classes that it implements. It would be a compile-time error if no such type argument list exists.

class A<X> {}
class B<Y> {}
mixin M<X, Y> implements A<X>, B<Y> {}
typedef Malias<Y extends num> = M<int, Y>;

class C1 extends A<int> with Malias {} // Infers `Malias<num>`.
class C2 extends A<String> with Malias {} // Compile-time error.
class C3 with Malias implements B<double> {} // Compile-time error.

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/249665