Skip to content
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

Adjust function literal return type inference to avoid spurious null #4210

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
+12 −1
Open

Adjust function literal return type inference to avoid spurious null #4210

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
149f0d2
Adjust function literal return type inference to avoid spurious null
eernstg Dec 17, 2024
c135c99
Review response
eernstg Jan 6, 2025
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
13 changes: 12 additions & 1 deletion 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,11 @@ Status: Draft

## CHANGELOG

2024.12.17
- Change the function literal return type inference rules to ignore
`return;` statements in generators (it doesn't actually cause null to be
returned).

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 @@ -324,7 +329,8 @@ schema.
`e`, using the local type inference algorithm described below with typing
context `K`, and update `T` to be `UP(flatten(S), T)` if the enclosing
function is `async`, or `UP(S, T)` otherwise.
- For each `return;` statement in the block, update `T` to be `UP(Null, T)`.
- If the enclosing function is not marked `sync*` or `async*`: For each
Copy link
Member

Choose a reason for hiding this comment

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

The "for each" seems redundant. How about "if the body contains any return; statement ..."?

Copy link
Member Author

Choose a reason for hiding this comment

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

All four items in this list use a similar quantifier (actually, they all use 'for each'). How would it be redundant? We're running an algorithm, and at this point it needs to iterate over the function body to find all occurrences of return .... Do you think it would improve the overall text to use a natural language version of recursion, rather than the iteration-ish "for each"?

`return;` statement in the block, update `T` to be `UP(Null, T)`.
- For each `yield e;` statement in the block, let `S` be the inferred type of
`e`, using the local type inference algorithm described below with typing
context `K`, and update `T` to be `UP(S, T)`.
Expand All @@ -339,6 +345,11 @@ schema.
`Stream<K>`; let `E` be the type such that `Stream<E>` is a super-interface
of `S`; and update `T` to be `UP(E, T)`.

In these rules, 'in the block' refers to return and yield statements that
will complete the execution of the function literal under inference, not
the ones, if any, that will complete the execution of a nested function
body.

The **actual returned type** of the function literal is the value of `T` after
all `return` and `yield` statements in the block body have been considered.

Expand Down
Loading