Allow generic function types as type arguments and bounds

[eernstg]

Feature specification: https://github.com/dart-lang/language/blob/master/accepted/2.14/small-features-21Q1/feature-specification.md

---

It is currently an error to use a generic function type as a type argument or as the bound of a type variable. This issue is a proposal to lift that restriction. Here is an example:

void f<X>() {}

main() {
  var xs = [f]; // Error: ''.. a function with type parameters cannot be used as a type argument'.
}

The restriction mainly serves to keep type inference tractable, but we do not prevent function types containing such types from being used as type arguments, so we presumably already handle the complexity arising from having such types when dealing with the parts of types that we already allow:

void Function<X>() g(void Function<X>() f) => f;

main() {
  var xs = [g]; // OK.
}

The restriction is at times inconvenient, e.g., because it forces data structures like lists to have less informative types than they could otherwise have, forcing expressions accessing elements of that list to use casts or dynamic invocations.

If the restriction is lifted then some new values of type Type can be obtained (because a generic function type can now be the value of a type variable), e.g., a reification of void Function<X>()—only reflection could deliver such reified types previously. But it was already possible to obtain a reification of, say, void Function<X>() Function(), so it might be a small change.

In any case, it involves both the analyzer and the common front end (because some types are no longer rejected), and it also involves backends (in particular, if there is something genuinely new in supporting these new reified types).

We need to ensure that it is indeed true for all implementations that they do not rely in any essential way on having this restriction. @mraleph, @stereotype441, if this restriction is lifted, is it your impression that this would break any invariants that our tools currently rely on?

@munificent, @leafpetersen, @lrhn, what do you think?

[lrhn]

I'd love to remove the restriction. I have already been hit by it once, when I tried to make a list of generic functions.

We are exacerbating the issue by actually inferring the type, and then reporting it as an error. That should never happen. We must not report errors in "code" that the user didn't write. We should refuse to infer a type instead of inferring a known invalid type.

I would be surprised if lifting the restriction introduces any problem for List<T Function<T>(T)> that wouldn't already be hit by List<T Function<T>(T) Function()>. The type occurs just as covariantly in the latter case.

(I can be surprised, I hope I won't be).

[lrhn]

See dart-lang/sdk#41871 for a concrete problem.

We should either allow generic function types as type arguments, or we should stop inferring them. Inferring something which is a known error is always bad usability.

[leafpetersen]

This might be a candidate for the small features release? I think it just involves removing an error check.

[lrhn]

I'll add it to the small features list. I hope implementations have not depended on the restriction in any way, but we'll see.

[mit-mit]

@lrhn is this done?

[mit-mit]

@eernstg are you aware of any outstanding work here?

[eernstg]

I think there's no further work. We have a full list of successful runs in https://dart-ci.firebaseapp.com/current_results/#/filter=language/generic/generic_function_type_argument&showAll.

@lrhn, please reopen if you are aware of something.