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.

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

Conversation

srawlins
Copy link
Member

No description provided.

dart-bot pushed a commit to dart-lang/sdk that referenced this pull request Sep 26, 2019
See the change to the spec: dart-lang/language#595

Change-Id: I5aeb20eb175f7018ecc99f398ea4d463b1e7874e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118920
Commit-Queue: Samuel Rawlins <[email protected]>
Reviewed-by: Brian Wilkerson <[email protected]>
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...

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
non-overriding instance method, a typedef, a generic function type, or a
Copy link
Member

Choose a reason for hiding this comment

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

"a typedef" is traditionally called a "a type alias".

The "a generic function type" case is different from the rest. Every other thing you mention is the syntactic category of a declaration, which makes sense since the sentence starts with "Declaring a ...". A "generic function type" is not a declaration, so it's not as clear what it means to "declare" one.

Why is it important that the function type is generic?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I may just be abusing the analyzer's AST for this concept, GenericFunctionType. It's not important that it be declared with type arguments. E.g.

void f6(callback()) {                 // Inference failure
  callback();
}

The issue there is that the return type of callback is implicitly dynamic; no inference is carried out. Is this just called a "function type?"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants