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.

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

return as an expression #3052

Closed
mattrberry opened this issue May 8, 2023 · 2 comments
Closed

return as an expression #3052

mattrberry opened this issue May 8, 2023 · 2 comments
Labels
feature Proposed language feature that solves one or more problems state-duplicate This issue or pull request already exists

Comments

@mattrberry
Copy link

The motivation for this is that I'd love to be able to return from a switch expression. i.e.:

String? someFunc(Node node) {
  final err = switch(node) {
    case Foo(field: String toReturn) => return toReturn,
    _ => 'some error message',
  };
  handleErr(err);
  return null;
}

Since return introduces a statement rather than expression, this isn't possible. I see in the language spec that that throw is an expression, making switch(x) { _ => throw 'foo' } legal. Is there a motivation for supporting throw and not other control flow keywords? In particular, I'm thinking return, yield, continue, break, and rethrow. Maybe it'd be easy to redefine these as expressions, which would be backwards compatible given that Dart already has an expression statement.

For a relatively mainstream language that has pattern matching and treats continue, break, and return as expressions, we can look at Rust's expression grammar.

(One other thing I'll point out with the introduction of switch expressions is that I'd love to run arbitrary groups of statements in an expression; something like #132)

@mattrberry mattrberry added the feature Proposed language feature that solves one or more problems label May 8, 2023
@eernstg eernstg added the state-duplicate This issue or pull request already exists label May 9, 2023
@eernstg
Copy link
Member

eernstg commented May 9, 2023

I'll close this issue as a duplicate of #2025.

@mattrberry, you might want to vote for #2025 and/or comment on it. Otherwise, you could create a new issue that puts more emphasis on why this is different from #2025.

@eernstg eernstg closed this as completed May 9, 2023
@mattrberry
Copy link
Author

Looks like #2025 covers my request. Thanks for deduping!

(I'm not happy with GitHub's issue search. I clicked through a few pages of searches for duplicates before posting.. :/ )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems state-duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants