Treatment of nested 'break'
Kevin Bourrillion
kevinb at google.com
Thu May 10 19:57:21 UTC 2018
I'm just going to say that naming a keyword as the argument of another
keyword seems novel and unprecedented for Java, and as such I think should
require pretty strong justification.
On Thu, May 10, 2018 at 12:12 PM, Guy Steele <guy.steele at oracle.com> wrote:
>
> > On May 10, 2018, at 3:06 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> >
> >
> >> I think these are both valid explanations, with different outcomes, but
> anyway it's fair to say that it would be confusing to have the latter
> perspective and then try to explain how a value break can get past a
> surrounding 'for' loop.
> >
> > One option is: you can't. While I agree there is code that one might
> like to write that is made cumbersome by this, it's a valid option, and not
> one that is utterly terrible.
> >
> > Another option is to extend the break syntax along the lines of the
> proposed continue syntax. Suppose for every continuable construct x (for,
> while, switch) we supported "continue x". So for every breakable construct
> y we could support "break y". If a for loop were enclosed in an expression
> switch, you could then say "break switch e". Then
> >
> > if (foo)
> > break;
> > else
> > break 3;
> >
> > becomes
> >
> > if (foo)
> > break for;
> > else
> > break switch 3;
> >
> > and it is much more obvious what is going on.
>
> If we are willing to pile up keywords in that manner, an alternate
> possibility is to spell a value-returning break in a different way:
>
> return switch <expression>;
>
> Then your example can become (I have added the implicit context):
>
> switch (…) { case 17 -> {
> …
> for (…) {
> ...
> if (foo)
> break;
> else
> return switch 3;
> … }
> … }
> … }
>
> The additional advantage of this approach is that it completely eliminates
> the syntactic ambiguity between
>
> break variableName;
>
> and
>
> break labelName;
>
> Given that we think most occurrences of “return switch” (or “switch
> return”, take your pick) will be abbreviated by -> anyway, this might be an
> acceptable approach.
>
> You can then still choose to go ahead and also allow things like
>
> break for;
> break switch;
> break while;
> continue for;
> continue switch;
>
> but that can be a separate decision; these become simply a way to avoid
> using statement labels.
>
> —Guy
>
>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180510/4094a78a/attachment.html>
More information about the amber-spec-experts
mailing list