Expression switch feedback

Stephen Colebourne scolebourne at
Sun Apr 8 22:25:15 UTC 2018

On 8 April 2018 at 15:49, Brian Goetz <brian.goetz at> wrote:
> I'll just also point out that, while I am as offended by mistakes as you
> are, my experience has taught me that the desire to "fix mistakes of the
> past" is one of the most dangerous temptations a language designer can
> indulge in.

We agree that statement switch is sub-optimal, and we agree that
fixing it is not the goal here. But not extending the sub-optimal
nature really isn't a bad goal (subject to what that brings in trade

> We could introduce a `fallthrough` statement

It is true that such a thing would be a no-op. But it would replace
lots of existing code that uses a comment for exactly this purpose
(and where the comment is checked by static analysis). I don't think
removing fall through by default would ever actually happen. Overall,
I'd say that adding a "fallthrough" keyword only makes sense if it has
actual semantic meaning in expression switch, thus making the case to
"backport" it to statement switch as a useful no-op.

> (Where I suspect you're
> going here is to make "falling into a pattern" an error, or at least a
> warning.  ... But just as we'd like to avoid making an artificial
> distinction between "pattern switch" and "constant switch", there's also no
> real distinction between constant label and pattern;

I agree that dividing constant patterns from more advanced ones should
be avoided as far as possible.

> What I think you may be missing is that we _are_ focusing on what will make
> sense 10 years hence -- by avoiding having two language constructs that are
> similar, but subtly different.

No, I'm not missing that - its very clear. But there are additional
factors here which play against it.

Firstly, the level of negativity there is for the current switch statement.
Secondly, the proposed expression switch has quite a lot of
differences to statement switch:
- auto default clauses for enums
- no return
- no loop-related break/continue
- shortform arrow operator

Its easy to focus on the first, but the second is more important (ie.
lets not debate how much the first is true or not).

The key question is at what point does the total of differences
between statement and expression switch become so great that it has to
be thought of as a separate language feature? I'd gently suggest that
our different perspectives stem from which side of that question we
judge the current proposal to sit.


More information about the amber-dev mailing list