Strange type comparison for functions

[iarkh]

• Dart SDK Version: 2.0.0-dev.58.0 (Wed May 23 20:44:51 2018 +0200)
• OS: Windows 10

The following code sample compares type of some Function object with one defined with typedef:

typedef F<X extends int> = void Function(X);
void func(x) {print(x+2);}

typedef F1<X extends int> = X Function();
String func1() {return "3";}

main() {
  print(func is F);
  print(func is F<dynamic>);
  print(func is F<int>);
  print(func is F<String>);

  print("--------------------------");
  print(func1 is F1);
  print(func1 is F1<dynamic>);
  print(func1 is F1<int>);
  print(func1 is F1<String>);
}

Sample output looks strange for me:

$> dart --preview-dart-2 test.dart
true
true
true
true
--------------------------
false
true
false
true

This shows that void func(x) {print(x+2);} is treated as F<String> - this is strange as F should have type argument which extends int (and String does NOT extends it),

At the same time, I see that void func(x) {print(x+2);} is not F1<String>, and it looks expected.

Also it;s not clear why func is F returns true, but func1 is F1 returns `false - should not results be the same here?

[eernstg]

I'm just about to write an update to the super-bounded-types.md feature specification which introduces the notion of variance for each formal type parameter of a parameterized typedef. With that, we will be able to avoid talking about checking both the actual type arguments vs. formal type parameter list and the right hand side of the typedef (using the new syntax, with the old syntax it's the same thing but distributed differently in the syntax), we will just note that each formal type parameter of a typedef has a certain variance and then we'll proceed from there.

This is relevant because these variances will guide the definition of what it takes to be a correct super-bounded type when it involves a parameterized typedef.

In particular, F<dynamic> will be a compile-time error because the type parameter is contravariant, and the replacement will yield F<dynamic> (we change Null to dynamic, but Null doesn't occur so that's a no-op), and the result is not regular-bounded.

Similarly, F1<dynamic> is correctly super-bounded because its type parameter is covariant, so we transform it into F1<Null> in order to check that it is correctly super-bounded, which it is because that is a regular-bounded type.

The above-mentioned feature specification update is upcoming, so we still need to think about the details, but the overall idea should be as described.

[eernstg]

New development: super-bounded-types.md will not be updated, the above-mentioned changes are part of this CL, where the language specification is being extended to cover super-bounded types and variance.

[eernstg]

Said CL has been landed as of commit bfa8be8.

[eernstg]

Closing: Given that this has been placed as an area-language issue, said commit bfa8be8 completes the effort.

I've created a new meta-issue in order to get it implemented: #33444. With that in place, F<dynamic> in the example program will be a compile-time error, so the different elements of that program may still give rise to issues, but will in any case need to be reconsidered. Please create new issues as needed when we get to that point.