I think i agree with you about the fact that the expression switch does need to
more on that in a folowing email.
I've been leaving this topic until we have ironed out the higher-order
bits, but this seems a good enough time to start this discussion.
I agree this is confusing, but I think it is also not likely to be
something people do naturally -- because the -> form, where it is
applicable, is so much more attractive -- so the risk of confusion is
low. Just as style guides say to users "if you're going to use fall
through, label it clearly", and most code does, style guides will guide
users away from this confusion.
I also agree with you that mixing arrows and colons is confusing.
Basically, your proposal is to use -> eveywhere, i think i prefer the opposite,
do not use arrow at all.
Using arrow in this context is disturbing because it doesn't mean the same
things if it's the arrow of the lambda or the arrow inside an expression switch.
This is a reasonable alternative, but I don't think it would be very
popular. I think people will really love being able to write:
case MONDAY -> 1;
case TUESDAY -> 2;
and will be sad if we make them write
case MONDAY: break 1;
case TUESDAY: break 2;
Not only will they be said, but they will point out that the "obvious"
answer was in front of our noses, and we did something different just to
be different. (You can easily imagine the "There those Java guys go
again, verbosity for its own sake" rants, but this time they might
actually be right, rather than the folks who can't spell "migration
compatibility" complaining about erasure.)
the problem is that currently -> means create a new function scope and not
creates a new code scope.
I think the scopes issue is a red herring.
So if do not mixing arrows and colons is an important goal and i think it is, i
think it's better to not use arrow.
Or just: avoid mixing arrows and colons.
Moreover, do we really need a shorter syntax given that we can use break and a
I suggest you do this poll at Devoxx. Make sure to wear flame-proof pants!
and now we can discuss about adding a shorter syntax by making break optional
if there is one expression.
... which we expect to be true almost all the time.