Treatment of nested 'break'

[Kevin Bourrillion]

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>