co19/LanguageFeatures/Subtyping/static/generated/records_fail_class_member_super_fail_A07_t01

[scheglov]

Just like this is a compile-time error:

final List<int> v = <dynamic>[];

It should happen IMHO when List is in a record type.

const t1Default = const (5, "6", b: []);

class ClassMemberSuper1_t02 {
  (int i, String, {List<num> b}) m = t1Default;
...

[scheglov]

It looks that there are many tests in this group which are generated (as the names say!).
So, I will wait for updates to re-run again for any other possible things to fix.

[scheglov]

The group of tests co19/LanguageFeatures/Subtyping/dynamic/generated/records_ looks to be generated from the same or similar source and has similar typos.

[sgrekhov]

Yes, these are generated tests. I'll fix the source and regenerate all of them

[sgrekhov]

I don't see an error here. List is not a <dynamic> here. IMHO we have here a case like

final List<int> v = const [];

which is not an error.

@eernstg please confirm

[eernstg]

Let's look at the original example again:

const t1Default = const (5, "6", b: []);

class ClassMemberSuper1_t02 {
  (int i, String, {List<num> b}) m = t1Default;
}

I would expect t1Default to obtain a declared type by inference, and the type would be (int, String, {List<dynamic> b}).

The initialization of m would then fail, because (int, String, {List<dynamic> b}) is not a subtype of (int, String, {List<num> b}), and it is also not dynamic.

The issue dart-lang/language#2503 asks the question whether we'd want to lift promotion to record types in a specific sense. This issue gets close, but it doesn't quite match.

One way to think about this lifting step is that it corresponds to performing the existing operation for each field (recursively, if we have nested records). So (int, String, {List<dynamic> b}) would be assignable to (int, String, {List<num> b}) if and only if int is assignable to int, String is assignable to String, and List<dynamic> is assignable to List<num>. But the latter is not true, so we still don't get assignability.

So we definitely do have an error here.

However, if we introduce lifting as described above then we could have the following:

const dynamic d = true;
const t2Default = const (5, "6", b: d);

(int i, String, {List<num> b}) m = t2Default;

With lifting, this initialization would be accepted at compile time (and throw at run time, of course), because dynamic is assignable to List<num>. But without lifting we just need to note that the type of t2Default isn't dynamic and it isn't a subtype, so it's a compile-time error.