Skip to content

Update strict-inference re: return types of setters, overriding methods #595

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update strict-inference re: return types of setters, overriding methods #595

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3af225e
Update strict-inference re: return types of setters and overriding me…
srawlins Sep 26, 2019
70aa2b8
Fix typedef
srawlins Oct 17, 2019
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
21 changes: 15 additions & 6 deletions resources/type-system/strict-inference.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -297,12 +297,14 @@ void main() {

### Function return types

Declaring a recursive local function, a top-level function, a method, a
typedef, a generic function type, or a function-typed function parameter
without a return type is an inference failure. The return type of non-recursive
local functions can always be inferred from downwards or upwards inference, as
it will have a body, and the return type of the body is known (even if there
are inference failures within).
Declaring a recursive local function, a top-level function, a static method, a
Copy link
Member

Choose a reason for hiding this comment

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

Is a recursive function always a problem?
Should it only be if the return type of the function depends on itself, and not, say:

foo(int x) => x <= 0 ? 0 : foo(x - 1).toString().length;

The return type of this function is no harder to deduce than a non-recursive function.

Copy link
Member Author

Choose a reason for hiding this comment

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

I thought type inference only calculated an omitted return type on a local function if that function was "non-recursive", as in, never references itself.

I don't see anything in the spec regarding this concept though...

non-overriding instance method, a type alias, a generic function type, or a
function-typed function parameter without a return type is an inference
failure. The return type of non-recursive local functions can always be
inferred from downwards or upwards inference, as it will have a body, and the
return type of the body is known (even if there are inference failures within).
Declaring a setter without a return type is allowed; the return type is assumed
to be void.

```dart
f1() { // Inference failure
Expand All @@ -320,9 +322,16 @@ void main() {

class C {
m1() => 7; // Inference failure
get g => 7; // Inference failure
int _s;
set s(int value) => _s = value; // OK (void assumed for setter)
static m2() => 7; // Inference failure
}

class D extends C {
m1() => 9; // OK (overrides C.m1)
}

typedef Callback1 = Function(int); // Inference failure
typedef Callback2(int i); // Inference failure

Expand Down