break seen as a C archaism

[Brian Goetz]

> I hope the point was still received that embedding statements inside 
> an expression for immediate evaluation appears to be novel for Java. 
> (All else being equal I assume that we are seeking to minimize novelty.)

Yes, we're seeking to minimize unnecessary novelty.  Winning is making 
things look like they were there all along.  (Sometimes we do better on 
this score than others; I don't hold out a lot of hope for "break n" 
being immediately recognized as something that was always lurking under 
the surface, especially given how much people hate break already, but I 
think we'll do pretty well on this score for integrating patterns in 
switch.)

I think a sensible next step would be for me to summarize the path by 
which we got here.  I'll try to write that up in the next few days.

In the meantime, let me probe for what's really uncomfortable about the 
current design point.  Is it:
  - That there are two ways to yield a value, -> e and "break e", and 
users won't be able to keep them straight;
  - The idea of using a statement at all to yield a value from an 
expression seems too roundabout;
  - That we are overloading an existing control construct, "break", to 
mean something just different enough to be uncomfortable;
  - Something else?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/02cac176/attachment.html>