- 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.
