Treatment of nested 'break'

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Kevin Bourrillion" <kevinb at google.com>, "Guy Steele" <guy.steele at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 10 Mai 2018 22:04:15
> Objet: Re: Treatment of nested 'break'

> 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.
You can also use any other word instead of break or break switch. 
By example, 
breakswitch 3; 

Rémi 

> 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 < [ mailto:guy.steele at oracle.com |
>> guy.steele at oracle.com ] > wrote:

>>>> On May 10, 2018, at 3:06 PM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
>>> > 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. | [ mailto:kevinb at google.com |
>> kevinb at google.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180511/8800fedf/attachment.html>