New JEP: Switch Expressions for the Java Language

[Brian Goetz]

Yeah, I totally get why you would prefer that.  But, I guarantee that for every one of *you*, there are others who would be appalled to find two similar but subtly different kinds of switch statements.  And people would have to learn both, because there’s lots of code out there that’s not going to get rewritten in the next ten years.  So, as sad as it may be, I see “fixing fall through” as neither a sensible priority for this project, nor even as something that will necessarily lead to a desirable result — so the return on investment is surely better elsewhere — and we’ve got plenty of other good candidates to work on.  (And no, no matter how simple it might seem to “just fix statement switch while we’re at it”, it’s not simple — its never simple.)  For better or worse, people understand switch as it is, and I think its easier for people to learn pattern matching when its layered on top of the (admittedly imperfect) switch that they already understand. 

While I agree that the *default* of falling through (the default could have been no fall through, with an opt-in to fall through, instead of the reverse) was probably a mistake, likely borne of copying too literally from C, there are in fact many uses of switch (generally in low-level parsing and networking code) that make extensive use of fall through, and would be painful to write without it.  So just because you don’t encounter it in your every day code (lucky you!), the notion of fall through is *not* a mistake, even if the default is wrong for most code.  (It’s in good company; there’s a long list of ways in which Java got the defaults wrong: fields are not final or private by default, classes are extensible by default, exceptions are checked by default, objects have a built in monitor, etc.)  

All that said, your data suggests that expression switches will be a huge improvement in your codebase — as we had hoped.  That’s great!  We’d love to hear more real-world experience of trying this stuff out in existing codebases.  




> On Dec 11, 2017, at 6:53 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> On 11 December 2017 at 19:59, Brian Goetz <brian.goetz at oracle.com> wrote:
>> If you search your heart, you'll realize that the break / fallthrough thing
>> is just an emotional "I think this was a mistake and I want an excuse to fix
>> it."  We didn't drop fallthrough from expression switch because we hate it
>> (though we might), but because it simply *doesn't make sense* in an
>> expression context.  But it does in a statement context -- regardless of how
>> much you don't like it.
> 
> Fall through is *the* biggest problem with switch and the reason why I
> tend to avoid use of the existing switch language feature completely.
> The extra break is painful and error prone - fall through shouldn't
> even be in the language. I've been burnt by fall through, and I'm sure
> many others have too. Some might call it hate, others might call it
> experience.
> 
> The key point the analysis showed was that most of our uses involve
> the return keyword in every case, precisely to reduce the risks of the
> error-prone use of break. Our code reviews would push developers
> towards using switch in that style precisely to reduce fall through
> risks. While a switch with return in every case can be converted to an
> expression switch, it is my opinion that doing so is not the best
> choice. However, that assumes that both expression and statement
> switches are equally safe, which is not what is proposed.
> 
> What we agree on is that there needs to be both an expression and a
> statement form of switch - they both have uses. And we agree that
> fall-through does not make sense in an expression switch.
> 
> Where we disagree is whether there should be a new statement switch or
> not (effectively deprecating the existing one). And we also disagree
> on whether fall-through is ever useful, and whether a new statement
> switch should mandate a default clause.
> 
> In my view, the existing switch statement is something to be avoided
> in most situations today, even when it would naturally be the right
> language feature, simply because of fall-through. This may come across
> as extreme, but developers like myself have learnt the hard way. The
> proposed changes don't fix this - I'll still try to avoid the existing
> switch statement (because of the risks of fall through), creating this
> weird imbalance - statement switch = bad, expression switch = good.
> 
> Looking forward, the pattern matching stuff should be built on a
> proper foundation, not one hobbled by this mistake from the past -
> Java needs a good high quality statement switch just as much as it
> needs a good high quality expression switch. One that experienced
> developers are willing to use, not forced to avoid. Given that this
> would be an easy IDE refactor, I'd much rather see a new statement
> switch alongside the new expression switch.
> 
> Stephen