Java: break and continue with an optional boolean condition

[Brian Goetz]

Now, my explanation happened to get a little lucky, in that we happened 
to be working on something conflicting _right now_, so the answer was 
immediately compelling.  But, it illustrates a more general aspect of 
designing a language that intends to be around for a long time: today's 
harmless irregularities inevitably become tomorrow regrets and constraints.

Suppose we had no idea we wanted to do break-value.  So suppose we did 
what you suggest.  At some time in the future, we might feel we'd have 
made a mistake; that would have spent one of our few remaining syntactic 
positions on something that didn't offer a sufficient return.  Saving 
those things for a future use, even if you don't know what it is, is 
often prudent.



On 6/11/2018 9:27 AM, George Radev wrote:
> Thank you Brian,
>
> Your explanation is clear and convincing; it will be really ambiguous 
> for yielding values.
>
> Thank you,
> George
>
> On Mon, Jun 11, 2018 at 4:10 PM Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Of course, you can do what you are suggesting relatively simply
>     and with
>     almost as few characters:
>
>          if (i > 10)
>              break;
>
>     Some languages let you do one-off conditional statements:
>
>          break if (i > 10);
>
>     In some cases, this is more readable than the full "if statement"
>     form,
>     because it telegraphs the intent to conditionally break a little more
>     clearly.  In some cases.
>
>     But, I don't find the proposed feature very compelling.  It is
>     neither
>     substantially more concise, nor does it open up interesting new
>     avenues
>     of expression -- it's mostly a linguistic "hack".
>
>     It also constrains with what else we might, in future, want to use
>     as an
>     argument to break or continue.  And in fact, expression switches use
>     `break` to yield a value for the expression.  (By contrast, this _is_
>     something that opens up interesting new avenues of expression.)  A
>     break
>     with a boolean would now be ambigious with break with a value to be
>     yielded to a switch.
>
>     The `{ statement } if { expression }` form is less problematic in
>     this
>     way -- but we still have not been able to convince ourselves that the
>     language would be better off with this form than without.
>
>     Cheers,
>     -Brian
>
>
>     > Would you consider a proposal for extending break and continue
>     with an
>     > optional boolean condition as reasonable?
>     > The idea can be summarized in the code example:
>     >
>     >      for (;;) {
>     >          ...
>     >
>     >          break (i > 10);
>     >          ...
>     >
>     >          continue (i <= 12);
>     >
>     >          ...
>     >
>     >      }
>     > //syntax will be:  break/continue [label] [boolean expression];
>     >
>     > This will increase the code readability of for, do and while;
>     and leave
>     > additional if and some curly brackets out of the picture.
>     >
>     > My arguments for such extension is that it solves the expressiveness
>     > concerns that Donald E. Knut explain in its article "Structured
>     Programing
>     > with GOTO statements" by describing the Ole-Johan Dahl proposal
>     for [loop
>     > while repeat] structure where the condition is not bound to the
>     beginning (
>     > do...while()) nor to the end of the repeating block (while()...)
>     which
>     > makes the controlled flow of the program more effective.
>     >
>     > Thank you for your time and consideration!
>     >
>     > With Regards,
>     > George Radev
>