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