This might not help, but perhaps think of it as a compound keyword;
"break switch" is not "break with an argument of switch", but a
multi-word keyword itself.
(Back in lambda, when we explored the consequence of using "return" in
lambda, and observed it foreclosed on nonlocal return should we ever
want to get there, we briefly discussed "long return" as a compound
keyword for that case. Same game.)
Personally if I saw "break while", I think I'd immediately know what
that means, and might even thank the author for being clear.
On 5/10/2018 3:57 PM, Kevin Bourrillion wrote:
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.ste...@oracle.com
<mailto:guy.ste...@oracle.com>> wrote:
> On May 10, 2018, at 3:06 PM, Brian Goetz <brian.go...@oracle.com
<mailto:brian.go...@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. |kev...@google.com
<mailto:kev...@google.com>
