Analyzer throws exception if function optional argument is omitted and it's parametrized.

[iarkh]

Dart SDK Version: 2.0.0_dev.68.0
OS: Windows 10

The following sample code example declares a function with one optional parametrized argument and than calls it without parameters:

class A<X> {}
testme<X extends A<X>>([X x]) {}

main() { testme(); }

It passes with dart and it seems like a correct result - indeed, if we don't set optional input argument, it should not affect the execution.
However, dartanalyzer throws an error here:

Analyzing test.dart...
  error - Couldn't infer type parameter 'X'.

Tried to infer 'A<dynamic>' for 'X' which doesn't work:
  Type parameter 'X' declared to extend 'A<A<dynamic>>'.

Consider passing explicit type argument(s) to the generic.

 at test.dart:4:10 - strong_mode_could_not_infer
1 error found.

I suppose analyzer should pass here too.

[iarkh]

I've just found even more simple example which fails similarly - in the following code

testme1<X extends List<X>>() {}
testme2<X extends List<int>>() {}

main() {
  testme1();
  testme2();
}

analyzer passes with testme2() and fails with testme1().

[chloestefantsova]

I'm implementing the checks of type arguments against the bounds in CFE currently and seeing tests with type variables declared like in the examples shown above (for example, X extends A<X>). I believe they indeed should be compile-time errors.

In the last example the missing compile-time argument provided by instantiate-to-bound is List<dynamic> for testme1, and it's a super-bounded type that could be used in many places. However, it does not pass the check against the bound, because List<dynamic> is not an f-bounded type and is not a subtype of List of itself, in particular.

Just in case I'm interpreting the feature spec incorrectly, I'll cc @eernstg.

[eernstg]

Agreed, i2b makes it testme1<List<dynamic>>(), and that's a generic function invocation so its actual type argument must satisfy the declared bound.

In particular, the given type argument is passed and may be used by code which was checked statically under the assumption that type parameter bounds are satisfied, so it would be unsound to allow any bound violations. So super-bounded types can come up here, but they can't be allowed. Just like they can't be allowed as actual type arguments in an instance creation.