Treatment of nested 'break'

Guy Steele guy.steele at
Thu May 10 19:12:15 UTC 2018

> On May 10, 2018, at 3:06 PM, Brian Goetz <brian.goetz at> 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)
		       return switch 3;
		… }
	    … }
	… }

The additional advantage of this approach is that it completely eliminates the syntactic ambiguity between

	break variableName;


	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.


More information about the amber-spec-experts mailing list