dart-lang / dart-lang/language
Improve inference of function literal parameter types
Nobody has claimed this yet.
- Dominant language
- TeX
- Stars
- 2.9k
- Forks
- 239
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 14
Description
Thanks to @dgreensp for bringing up this issue in this comment!
Consider the following program:
T wrap<T extends void Function(int)>(T t) => t;
void main() {
// Type of `x` inferred as `dynamic`, but we would prefer `int`.
final func = wrap((x, [String? y]) { x as int; });
func(1, "a");
print(func.runtimeType); // '(dynamic, [String?]) => Null'.
func("x", "y"); // Throws at run time.
}
The ability to use a function type as a type parameter bound is very useful in this kind of situation because the return type of wrap will then preserve the information about the entire signature of the actual argument (e.g., that it has some optional parameters as well as the required positional parameter that it must have in order to be a subtype of the bound).
Hence, we'd want to enhance type inference such that x gets the type int, rather than changing the code to express that type separately:
void Function(int) wrap(void Function(int) t) => t;
void main() {
// Type of `x` inferred as `dynamic`, would prefer `int`.
final func = wrap((x, [String? y]) { x as int; });
// func(1, "a"); // Compile-time error, forgot the optional parameter.
func(1); // OK.
(func as Function)(1, "a"); // OK, also at run time, but unsafe.
// func("x", "y"); // Compile-time error.
// func("x"); // Compile-time error, which is an improvement.
(func as Function)("x", "y"); // Throws at run time, which is good.
}
Note that we can't enable the flexibility of the original declaration because the type variable would need to be bounded from below (and we don't have that at this time, cf. https://github.com/dart-lang/language/issues/1674):
T wrap<T extends void Function(S), S super int>(T t) => t;
We could consider the following change to the rules about inferring the signature of a function literal, described in this section:
Current text:
Function literals which are inferred in a non-empty typing context where the context type is a function type are inferred as described below.
Proposed addition:
In the case where the context type is a type variable which is bounded by a function type
F, the declared types of formal parameters of the function literal that do not have a type annotation will be based onF.
It would be possible to use a more general parameter type for each of these parameters, but I do not think this will be helpful in practice: We're passing a function literal like (..., x, ...) {...} and we are using x in the body, so we probably want the declared type to be as special as possible. That is, this parameter type should be exactly the type which is specified in the context type (if it's a function type) or in the bound of the context type (if it's a type variable which is bounded by a context type). We already do the former, I'm just proposing that we should also do the latter.
@dart-lang/language-team, WDYT?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the function-literal return-type inference section in resources/type-system/inference.md, then trace the issue's example where the context is a type variable bounded by a function type. Compare the current rule with the proposed addition and determine whether the specification should adopt it; done means a language-team decision and an agreed specification change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dart
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100