Switch expression fall through

[Stephen Colebourne]

On 14 March 2018 at 16:30, Gavin Bierman <gavin.bierman at oracle.com> wrote:
>> On 13 Mar 2018, at 23:15, Stephen Colebourne <scolebourne at joda.org> wrote:
>>
>> A recent email to amber-spec implies that expression switch will
>> support fall-through.
>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000332.html
>>
>> Is this true? If so, on what basis is this justified?
>>
>> (Fall through in switch is the spawn of the devil. Allowing it in the
>> brand new expression switch would be horrific IMO.)
>
> If you write all your expression switches using the -> form exclusively, then you will be able to forget that fall-through even exists.

Yes. I am reading amber-spec. But being outside the spec-experts loop
I can't comment in real time. I do however find myself cheering Kevin
on to keep challenging this. His recent mail about whether the design
is targetting real developers, and not just compiler/language experts
chimes exactly with where I'm at:
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-March/000343.html

In both current design issues (raw string literals and expression
switch) I fully understand why the Oracle team has come to the
conclusions they have. From a pure language design POV they make sense
- the explanations are all perfectly rational. Yet in both cases they
feel like the wrong conclusions for Java developers beyond the expert
level. And they don't have that sense of blending in. That judgement
is of course highly subjective, which is why I spent time in another
thread highlighting how the raw string literal design has far far too
many puzzlers to take that discussion beyond pure subjectivity.

Getting back to expression switches, Brian asked "In the meantime, let
me probe for what's really uncomfortable about the current design
point". This was wrt using break to return a value, but I think the
narrow point is merely a manifestation of the difficultly of
integrating the whole feature. Specifically:

* Java has no way to return a value from a block, except where it is a
method in disguise (lambdas, inner classes)
* Java has never previously converted a block based control-flow
statement to an expression
* the closest parallel is if..else, which has a completely different
form (ternary) as an expression
* ternary expressions do not have blocks
* I can't remember ever refactoring a ternary to if..else

Given the above, the oft-repeated mantra of wanting to extend the
existing switch statement is a very odd place to drive the feature
from. Everyone wants a feature that fits well into Java, but it can be
argued that a completely different syntax closer to ternary would make
as much sense as extending switch. eg.:

return (dayOfWeek) ??
    case MONDAY: "M"
    case TUESDAY: "Tu"
   ....

(Discussion of extending switch to expressions have so far assumed the
first set of braces between switch and case, but it need not be that
way. Since expressions in Java today don't have braces unless they are
defining methods, I'd argue that expression switches fit much better
without those braces. This syntax form would also look fine passed
directly to a method in a way that a brace-based form would not.)

Consider Kevin's comment "So, from my perspective, if we just adopt a
style rule for Google Style that when using switch in an expression
context one should stick to `->`, I might have basically what I want."
This should be a huge red flag to the proposed design. That the best
teams will ban the use of a significant proportion of the new feature
on arrival is surely wrong.

(Again, I completely understand the "N case is significantly different
from the 2 case" argument for why blocks in expression switches might
be more common. Yet I still contend as Kevin and Remi have that blocks
are an edge case here that blocks a much nicer solution to the problem
space. Lambdas are not a suitable comparison as they define methods,
so form a completely different conceptual grouping for developers).

In summary, a key issue here is that blocks in Java have never
returned values. And the syntax choices for making them do so all seem
poor. So, is using `break` to return a value wrong? Perhaps its simply
the wrong question.

Stephen