Skip to content

Specification: Specify that a function literal in an initializer list must be parenthesized #35674

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

Closed
eernstg opened this issue Jan 16, 2019 · 1 comment
Labels
area-specification (deprecated) Deprecated: use area-language and a language- label. closed-duplicate Closed in favor of an existing report type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@eernstg
Copy link
Member

eernstg commented Jan 16, 2019

Cf. #35673, it is currently not specified that the following is an error:

class A {
  final x;
  A(p): x = (p) => 42 {}
}

because the initializing expression in a <fieldInitializer> cannot be a function literal (the problem is that this in some cases introduces the need for an unlimited lookahead, and it's simply confusing for developers because of the syntactic ambiguity of a potentially large amount of code).

We should specify this. It may be possible to relax these rules somewhat, e.g., by noting that (int p) cannot be an initializer, so x = (int p) { return 42; } would not have the ambiguity: We definitely need to parse a function literal, and we can see, after a few tokens, that the {...} is part of that function literal, and then it's required to have a constructor body or a semicolon afterwards. We might also insist that it is an error, because it's still a source of confusion for human readers that we have this big {...} that might be a constructor body.

@eernstg eernstg added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) area-specification (deprecated) Deprecated: use area-language and a language- label. labels Jan 16, 2019
@eernstg eernstg added the closed-duplicate Closed in favor of an existing report label Jan 22, 2019
@eernstg
Copy link
Member Author

eernstg commented Jan 22, 2019

Closing as duplicate of #11509.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-specification (deprecated) Deprecated: use area-language and a language- label. closed-duplicate Closed in favor of an existing report type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

1 participant