break seen as a C archaism
Brian Goetz
brian.goetz at oracle.com
Wed Mar 14 18:32:15 UTC 2018
> - That we are overloading an existing control construct, "break",
> to mean something just different enough to be uncomfortable;
>
>
> To some degree yes, since `break <identifier>` already means something.
Digging deeper: If we spelled "break <value>" differently (yield, emit,
defuse), would it be significantly different? I think reusing "return"
is worse than reusing "break", but there are other choices. (Though
introducing a new keyword has its own user-model challenges.)
> Part of it is that I know how to make sense of (a) current switch and
> (b) a simple well-behaved nice expression switch that only uses `->`,
> but knowing that I may have to deal with (c) code that is some mixture
> between the two feels like additional level of complexity to me. Even
> if from an implementation standpoint it's not.
I like to think that this is pedagogical, stemming from thinking of
switch expressions and switch statements as unrelated things. If we
view expression switches as a generalization of existing switch, I think
that the dichotomy between A/B can go away. But only if there is a
clear enough explanation that everyone will eventually receive.
C is still an issue, and I do get the discomfort of mixing both -> and :
cases, and I agree that good style will minimize mixing. Outlawing
mixing entirely isn't a great answer, though; its too common to use ->
for all the cases except default, which often needs statements to do its
thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/a26678cd/attachment.html>
More information about the amber-spec-experts
mailing list