expression switch vs. procedural switch
Guy Steele
guy.steele at oracle.com
Wed Mar 14 16:12:34 UTC 2018
> On Mar 14, 2018, at 12:16 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>
> De: "Kevin Bourrillion" <kevinb at google.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 14 Mars 2018 16:55:24
> Objet: Re: expression switch vs. procedural switch
> On Tue, Mar 13, 2018 at 1:02 PM, Kevin Bourrillion <kevinb at google.com <mailto:kevinb at google.com>> wrote:
>
> The more I have thought about it, the more I believe that 95% of the entire value of expression switch is that it isn't procedural switch, and is easier to reason about than procedural switch because of all things it can't do:
> can't miss cases
> can't return
> can't break/continue a containing construct
> can't fall through
> (for constants or other disjoint patterns) can't depend on the order of cases.
> As far as I can tell, its limitations are exactly what make it useful.
>
> Brian reminded me in the other thread that as long as we voluntarily stick to `->` style for all cases, we get all of this. 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.
>
> yes, but it's what i detest the most about C++, everyone has its own dialect.
What is the solution? A style requirement that every programmer use every feature in the language at least once in any program? (I have known programmers like that, and their code was not necessarily any easier to read.)
I am sympathetic to your feeling about this, but have no idea how to encourage it or enforce it. You really can’t prevent a programmer, or group of programmers, from sticking to a subset that makes them happy.
—Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/40ef4cc8/attachment.html>
More information about the amber-spec-experts
mailing list