Treatment of nested 'break'

[Kevin Bourrillion]

(Both numbers are supposed to say 0.07%.)

On Thu, May 10, 2018 at 5:06 PM, Kevin Bourrillion <kevinb at google.com>
wrote:

> On Thu, May 10, 2018 at 1:04 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> 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.
>>
>
> Well, then multi-word keywords are the thing that is novel and should
> require very strong justification. :-)
>
> But no. I've gotta disagree with this: If we tell users that they can do
> "break while", "break for", "continue while", "continue for", and "break
> switch", no one's mental model will be that those are five different new
> keywords. There is a very obvious orthogonal separation between (first)
> what to do and (second) at what scope to do it. That's what I meant by
> "argument of".
>
>
> Personally if I saw "break while", I think I'd immediately know what that
>> means, and might even thank the author for being clear.
>>
>
> It's not bad.
>
> Here's a quick tidbit from our codebase:
>
> - Labeled break/continue is *unfathomably* rare -- a rough estimate is
> 0.07% of all break/continue statements. (Just to be clear, no, we don't
> have any kind of style guide rule about avoiding the use of labels, or
> static analysis complaining about it, etc.)
>
> - And even among this small 0.3%, in virtually every one of them the
> surrounding loops are of the same kind, so `break <keyword>` would not be
> applicable.
>
>
>
>
> 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.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
>>
>>
>>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>



-- 
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/abccca88/attachment.html>