Treatment of nested 'break'
Kevin Bourrillion
kevinb at google.com
Fri May 11 00:07:57 UTC 2018
(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>
More information about the amber-spec-experts
mailing list