break seen as a C archaism
    Peter Levart 
    peter.levart at gmail.com
       
    Fri Mar 16 09:39:05 UTC 2018
    
    
  
Expanding on do...
On 03/16/18 09:50, Peter Levart wrote:
> And if "while (false)" could be optional, we get:
Or better yet, make "while (true)" optional even in statement do, so we 
can finally get away with some more boilerplate:
for (;;) {
}
or
while (true) {
}
and simply do:
do {
}
For e-do, the choice of default "while (true)" is fine, because it 
aligns with the fact that there has to be a break <value> somewhere to 
exit it anyway because it has to yield a result. But there will be some 
danger that a programmer codes an infinite loop by mistake.
>
> doSomething(
>     par1,
>     do {
>         // compute result...
>        break resut;
>     },
>     par3
> );
>
Expanding on e-do... It could be a building block for e-switch. Remi is 
advocating for expression-only case(s) in e-switch. Combined with e-do, 
we could write:
int y = switch (x) {
     case 1 -> 2;
     case 2 -> 3;
     case 3 -> do {
         r = ...;
         break r;
     };
};
What we loose here is fallthrough. And we still have "break" here too.
It's unfortunate that we couldn't find a way to have an e-{block} of a 
kind when lambdas have been conceived. That way we could get away with 
expression-only lambdas and expression-only cases in e-switch using the 
same building block. But I guess the statement lambda has its weight 
with its "return" sticking out and reminding us about the scope.
Regards, Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180316/7536bb69/attachment-0001.html>
    
    
More information about the amber-spec-experts
mailing list