NNBD: Both dart and analyzer allow inherit two interfaces with incompatible type parameters: `Object?` vs `dynamic` and `Object?` vs `void`.

[iarkh]

Dart VM version: 2.8.0-edge.40f23c735f04433e4fc334fbd674474bd3de0f8b (Tue Jan 28 01:14:48 2020 +0000) on "linux_x64"

The following source code declares classes X1 and X2 which inherit classes with incompatible type arguments:

class A<T>{}
class B implements A<Object?> {}

class C implements A<void> {}
class D implements A<dynamic> {}

class X1 extends B implements C {}
class X2 extends B implements D {}

main() {}

This code throws compile error with previous dart versions (for example, 2.7.0) and it seems like dart should do so, for example, see Classes defined in opted-in libraries in NNBD Spec:

If a class C in an opted-in library implements the same generic class I more than once as I0, .., In, and at least one of the Ii is not syntactically equal to the others, then it is an error if NNBD_TOP_MERGE(S0, ..., Sn) is not defined where Si is NORM(Ii). Otherwise, for the purposes of runtime subtyping checks, C is considered to implement the canonical interface given by NNBD_TOP_MERGE(S0, ..., Sn).

However, current both dart and analyzer do not throw error here, sample output is:

$ dart --enable-experiment=non-nullable test.dart
$ dartanalyzer --enable-experiment=non-nullable test.dart
Analyzing test.dart...
No issues found!

[lrhn]

I believe that NNBD_TOP_MERGE(A<Object?>, A<dynamic>) is well-defined.
We are still arguing whether it should be A<Object?> or A<dynamic>, the current specification says A<Object?>, but it will be one of them, and not an error.

@eernstg Agree?

[iarkh]

OK, but anyway - Object? vs void is incorrect case and exception should be thrown?

[lrhn]

NNBD_TOP_MERGE(A<Object?>, A<void>) is currently defined to give A<void>, and it's not an error either.

[iarkh]

NNBD_TOP_MERGE(A<Object?>, A<void>) is currently defined to give A<void>, and it's not an error either.

OK, so seems like this bug should be closed as work-as-designed.

[eernstg]

@lrhn wrote:

Agree?

Yes. The approach based on normalization and then nnbd top merging is actually considerably more flexible than the old rules: We had 'It is a compile-time error if a class $C$ has two superinterfaces
that are different instantiations of the same generic class', and even though it was never spelled out exactly what "different" meant, it would surely not be easy to argue that List<FutureOr> and List<void> aren't different. But with the new rules they can coexist.

So we do allow more. In particular, the following assumption is too strong:

@iarkh wrote:

This code throws compile error with previous dart versions
(for example, 2.7.0) and it seems like dart should do so .. in NNBD