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