Skip to content

Adjust function literal return type inference #3149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed

Adjust function literal return type inference #3149

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
0a70ae2
Typo
eernstg Jun 15, 2023
4917472
Correction: must flatten the context type when testing T <: R, too
eernstg Jun 15, 2023
01e0a9b
Clarified the meaning of `S`
eernstg Jun 15, 2023
322a81e
Clarify the logic (when each sentence is applicable)
eernstg Jun 15, 2023
20b0dc6
Whitespace
eernstg Jun 15, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 14 additions & 3 deletions resources/type-system/inference.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,10 @@ Status: Draft

## CHANGELOG

2023.06.15
- Adjust function literal return type inference to avoid spurious application
of `flatten`.

2022.05.12
- Define the notions of "constraint solution for a set of type variables" and
"Grounded constraint solution for a set of type variables". These
Expand Down Expand Up @@ -345,15 +349,22 @@ all `return` and `yield` statements in the block body have been considered.
Let `T` be the **actual returned type** of a function literal as computed above.
Let `R` be the greatest closure of the typing context `K` as computed above.

*Now compute `S`, which is the future value type of an `async` function, the
element type of a generator function, and the return type of other functions.*

With null safety: if `R` is `void`, or the function literal is marked `async`
and `R` is `FutureOr<void>`, let `S` be `void` (without null-safety: no special
treatment is applicable to `void`).

Otherwise, if `T <: R` then let `S` be `T`. Otherwise, let `S` be `R`. The
inferred return type of the function literal is then defined as follows:
If the previous paragraph did not yield a value for `S`: When the function is
marked `async`: if `T <: futureValueType(R)` then let `S` be `T`; otherwise let
`S` be `futureValueType(R)`. When the function is not marked `async`: if `T <:
R` then let `S` be `T`; otherwise let `S` be `R`.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to use futureValueType(R), not flatten(R). If we were to use flatten then we'd carry ? over from the context. So we could have a context type that wants a Future<num>?, then we'd get int? as the value of R, and then we'd get an inferred return type of Future<int?> where the context wants a return type of Future<int>?, and that's a type error.

Future<int>? Function() f = () async => 1;

In this example R is Future<int>? and flatten(R) is int?. But we don't want the function literal to have a return type of Future<int?>, it should be Future<int>.


The inferred return type of the function literal is then defined as follows:

- If the function literal is marked `async` then the inferred return type is
`Future<flatten(S)>`.
`Future<S>`.
- If the function literal is marked `async*` then the inferred return type is
`Stream<S>`.
- If the function literal is marked `sync*` then the inferred return type is
Expand Down