JEP proposed to target JDK 12: 325: Switch Expressions (Preview)

Ryan Schmitt rschmitt at pobox.com
Wed Aug 29 00:06:48 UTC 2018


I seem to recall that people made similar predictions about the six-month
release train, that it wouldn't work because the temptation to deviate from
the basic principle would be too great. And yet it seems to be working so
far, so I don't really see any cause for concern over experimental language
features.

On Tue, Aug 28, 2018 at 4:51 PM, Ben Evans <benjamin.john.evans at gmail.com>
wrote:

> Thank you Brian for taking the time to lay out the reasoning.
>
> I'm going to have to disagree with the conclusions that you've
> reached, but we definitely need to move on.
>
> The only other point I wanted to make is that I think it is rather
> unfortunate that the first Preview language feature we're getting is
> this one, as it is so obviously a foundational feature for something
> much more far-reaching. I worry that, far from being an area where we
> can change course based on experience, once this has shipped in 12 it
> will basically become an invitation for Sunk Cost Fallacy reasoning,
> regardless of how usable the feature is in practice. I guess we'll
> find out in March...
>
> Thanks,
>
> Ben
>
> On Mon, 27 Aug 2018 at 20:05, Brian Goetz <brian.goetz at oracle.com> wrote:
> >
> >
> > >
> > > The few objections raised here are not new, having already been raised
> > > and answered over on the amber-dev and amber-spec-experts lists.  I’ve
> > > therefore targeted this JEP to JDK 12.
> > >
> >
> > As Mark says, the issues raised on this thread were already considered
> > and discussed at some length during the design of the feature.  But, for
> > the convenience of readers here, I will summarize for the record some of
> > the reasons why these suggestions were not incorporated into the final
> > design of the feature when they came around the first time.
> >
> > Stephen raised several specific objections, which I'll summarize as:
> >
> >   - You're increasing complexity by adding three features, one of which
> > is silly, and which gives us more fallthrough rather than less, which is
> > surely a move in the wrong direction!
> >   - I don't love the syntax.
> >   - You should have created a new syntactic form (hereafter, "snitch",
> > for "new switch") and left classic switch for dead, rather than piling
> > more complexity on existing switch, because existing switch is
> > hopelessly tied to the dumb idea of fallthrough.  Die, fallthrough, die.
> >
> > Ben expressed general agreement, and specifically for the "you should
> > have killed switch and made something new" position.  While I understand
> > where these opinions come from, and we did consider these issues
> > seriously, we concluded that abstracting the existing switch construct
> > as we did was a better long-term path.
> >
> > Ben also raised the excellent point that language design is a balance
> > between the interests of experienced developers and of newcomers -- a
> > concern we struggle with in every single feature, and which also played
> > into our decision here.
> >
> >
> > The first sentiment, which I've seen expressed in a few places, relies
> > on a somewhat tortured notion of "feature".  We have not added three
> > features (enhanced statement switch, classic expression switch, enhanced
> > expression switch), as much as added _two_ features, defined at a very
> > different level:
> >
> >   - The ability for switch to be an expression or a statement
> >   - The choice of classic case labels or enhanced case labels, where the
> > latter are single consequent, fallthrough-free, and free of the
> > confusing scoping of the classic switch block (essentially, fixing most
> > of the things people complain about with respect to switch.)
> >
> >   These features work orthogonally, so that you can mix and match them
> > freely, and I don't think anyone could reasonably object that either is
> > frivolous or undesirable.  So while they do give rise to four
> > combinations, these combinations are not features in themselves.
> > Defining the improvements to switch as orthogonal choices makes the
> > design and implementation _simpler_, not more complex, as we can then
> > reason about the semantics of a particular combination based on the
> > semantics of simpler orthogonal primitives.
> >
> > The fact that some combinations of these features are more desirable
> > than others is not evidence that a mistake was made.  This is often the
> > natural consequence of providing simple primitives that can be combined
> > orthogonally; some of the combinations are always going to be more
> > sensible than others, and that's fine.  So while "classic expression
> > switch" may seem silly, and will almost certainly be rarely used in
> > practice, that doesn't mean that we should distort the language design
> > to prevent it.  In fact, doing so would increase, not decrease, the
> > complexity, as it introduces arbitrary constraints and special cases.
> > (As a possibly tortured analogy, while we might almost never write a
> > combination of public setter and private getter, that's no reason to try
> > and outlaw that combination.)
> >
> > As to syntax preferences ... because syntax is so deeply subjective,
> > there is never going to be a syntax that satisfies everyone.  And,
> > people being what they are, they tend to only complain about the things
> > they disagree with, and are quiet about the things they agree with.  So
> > any syntax decision (whatever it is) is going to be met with some degree
> > of "I don't like it" or "I would have preferred X" -- but again, that
> > isn't necessarily actionable or dispositive.  The syntax choice we made
> > here is consistent with how similar things are done in similar languages
> > -- and we think it will, perhaps after a few days of initial
> > brain-retraining, be well-understood and accepted by Java developers.
> >
> > The final concern is a combination of pragmatism and language evolution
> > philosophy -- whether it is better to abandon an existing feature and
> > create a replacement, or to try and rehabilitate or generalize an
> > existing feature.  While we asked ourselves many times whether switch
> > could indeed be rehabilitated (not just in the context of this smaller
> > feature, but in the context of the bigger feature arc of pattern
> > matching), we found that, at each turn, it was more practical to
> > rehabilitate it than one might have initially thought.  And we felt it
> > better to build on the existing feature that is well understood and well
> > documented, than to create a wholly new one, just because the old one
> > was imperfect.
> >
> > Ben expressed concerns along the lines of "think of the students" with
> > respect to the proliferation of switch forms, but the reality with a
> > separate "snitch" form would most likely be worse.  Students would not
> > be fully absolved of the need to learn "old switch", not only because
> > they will encounter code that uses it, but because snitch would almost
> > certainly be tilted towards the "happy cases", which, while common, are
> > not universal.  And by un-anchoring snitch from switch, the differences
> > would likely be more arbitrary.  So new students would encounter a
> > language with two suspiciously similar constructs, but subtly different
> > in harder-to-understand ways, and wonder why there are two ways to do
> > it.  The burning hulk of "old switch" would lie forever on the roadside,
> > but unable to be ever hauled away.  Its nice to think that we can invent
> > the ideal "snitch" construct, and just leave "switch" in the past, but
> > that's a fantasy.
> >
> > Now, if switch were truly broken, it might be different.  But for all
> > the distaste of fallthrough-by-default, the existing switch construct is
> > _not_ fundamentally broken; it's not just what we'd design now if we had
> > a clean sheet of paper.  (BTW, fallthrough itself is not a problem, and
> > sometimes is essential; the real mistake was fallthrough _by default_.)
> > Therefore, while we did consider whether it would be necessary to retire
> > "switch" to pasture, we found no evidence that this was actually
> > necessary -- and found that it was possible to enhance switch to support
> > all the desired behaviors, rather than to abandon it, however tempting
> > the latter course might initially seem.  Enhancing switch builds on the
> > existing understanding of Java developers; abandoning it for snitch
> > invalidates that understanding.
> >
> > At a meta level, this inclination -- "just abandon switch and build
> > something better" -- illustrates a common temptation that is best
> > avoided: over-rotating towards the desire to "fix" the mistakes of the
> > past because they offend us, and because the current opportunity seems
> > "the last chance" to right a wrong that's been bugging us for years.
> > These are natural motivations, but they are frequently siren-songs that
> > lure us away from the path that calmer reason might otherwise have
> > chosen.  Yes, it would have been better if switch were designed
> > differently 20 years ago, but that was billions of programmer-hours and
> > lines of code ago, and the calculus is very different with such a large
> > existing base of code and user understanding.  So, while I understand
> > why it feels like an "opportunity missed", the cost of "seizing" this
> > opportunity was too great, and the benefit too small.  Its natural to
> > regret that we can't fix the mistakes of the past, but in this case, it
> > would have been the wrong choice.
> >
> > The preview mechanism will allow us to gather feedback on the feature
> > from actual use, rather than theorizing from no examples, and
> > potentially adjust the specification before final release if warranted.
> > So if any _new_ issues up come as a result of actual experience, we are
> > happy to hear about them.
> >
> >
>


More information about the jdk-dev mailing list