[ddc] Wrong behaviour for a `class C = Object with M;` mixin usage.

[kallentu]

mixin M {
  int x = 0;
}

abstract class C = Object with M;

class CMixin with C {}

void main() {
  var cMixin = CMixin();
  var value = cMixin.x;
  print('We expect 0 here: $value');
}

In Dart2JS, we get the output of 0, while in DDC we get null for this example. This happens specifically with this mixin syntax.

[kallentu]

cc @nshahan

[annagrin]

Thanks @kallentu! Looks like we don't call the M's constructor when constructing CMixin.

[lrhn]

From a specification point of view, M has no constructor. Object with M, like any mixin application, is given a forwarding initializing constructor for each accessible generative superclass constructor, which is also where instance fields get initialized.

Each mixin application creates a new constructor, with a new target for its super() invocation.

[eernstg]

This issue might have been resolved at this time. The example would look as follows today (in order to avoid irrelevant compile-time errors):

mixin M {
  int x = 0;
}

abstract mixin class C = Object with M;

class CMixin with C {}

void main() {
  var cMixin = CMixin();
  var value = cMixin.x;
  print('We expect 0 here: $value');
}

This programs runs and prints 'We expect 0 here: 0' on DartPad based on Dart SDK 3.11.0-49.0.dev. Is there a configuration where it still fails?

[nshahan]

Is there a configuration where it still fails?

Yes, if there is a test for this it would be failing on ddc-linux-chrome and passing on ddc-canary-linux-chrome at this time. We are using the passing configuration on the DartPad, and external Flutter web. We're in the process of rolling it out to external non-Flutter web and beginning the investigation into rolling it out to internally as well.

Until we get all of the integrations migrated we should probably keep this issue open.