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
Open

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

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
17a97e5
Adjust function literal return type inference to avoid spurious null
eernstg Dec 17, 2024
15c50c5
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
8 changes: 7 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)`.
Copy link
Member

Choose a reason for hiding this comment

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

I really think it should change the return type to void, but I guess that's a bigger change.

Copy link
Member Author

Choose a reason for hiding this comment

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

Perhaps that's already covered pretty well?

For function literal return type inference, the type void is given special treatment: If the context type has a return type which is void then the return type of the function literal is also taken to be void.

void main() {
  void Function() f = () { return; }; // Return type of function literal is `void`.
  f = () { return 3; }; // Error, can't return an `int` from a void function.
}

When the return type from the context type is any other type, the inferred return type of the function literal will not be void unless it actually returns an expression of that type.

void main() {
  Object? Function() f = () { return; };
  print(f.runtimeType); // Something that means `Null Function()`.
  f = () { return print('Hah!'); };
  print(f.runtimeType); // Something that means `void Function()`.
}

This means that the function will always be treated as a void function when this is what the context expects, and it will almost always be treated as a non-void function when this is what the context expects.

In the case where a return; statement occurs in a function literal whose inferred return type is not void, we already have other diagnostics:

void main() {
  int? Function(bool b) f = (bool b) {
    if (b) {
      return; // Error: The return value is missing after `return`.
    } else {
      return 1;
    }
  };
}

I think this would already deal with the potential code smells that you were targeting.

Copy link
Member

Choose a reason for hiding this comment

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

Not: "in the block" is imprecise. It can be read to include the bodies of nested functions, and it can be read as only applying to immediate sub-statements of the block.
Maybe "return; statements returning from this function" or something?

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, done!

- 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 Down
Loading