Expression switch - an alternate proposal

[Stephen Colebourne]

On 9 April 2018 at 15:28, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Here is the impact on some code:
>>     default: -> {
> I assume you mean
>     default -> { }

No, it was an arrow followed by a block that ended in throw.

> The primary non-syntactic difference is that started with a "no fallthrough
> ever in expression switch" requirement, whereas we're still deciding on what
> constraints to put on fallthrough.  But that's not a difference, as much as
> you've already made up your mind and we haven't.

My proposal clearly offered the option of a fallthrough keyword. Maybe
that means its not a block expression?

> I have a real aversion to introducing a block
> expression syntax here.  It would suck to have a block expression syntax
> that's only good in switches; it would suck in different ways to have one
> that is good everywhere.

I understand the reluctance to have a block-expression, and I agree
with the reluctance. But in semantic terms, the desirable semantic is
either:
- a block of code that must provide a result or throw
- a block of code that must provide a result, throw or explicitly fallthrough

If you haven't ruled out making fallthrough in e-switch an error,
aren't you necessarily considering having what amounts to a block
expression?

Maybe just don't call it a "block expression" and we can both be happy :-)

(Perhaps its the arrow that is confusing the debate because that
implies an expression on the RHS? I'm not fussed about keeping the
arrow!)

> So, what you've done is move a little bit down "it looks different, so
> people won't be surprised that it acts different" (e.g., different
> exhaustiveness behaviors) spectrum.

The exhaustiveness doesn't push me that way. Its the different rules
on return/continue/break/fallthrough. When adding those semantic rules
(which I agree with) developers also need to be able to know that the
rules apply. I find the current proposal obfuscates rather than
enables readability on this. I put this point as #1 on my ordered list
for a reason.

Stephen