expression switch vs. procedural switch

[forax at univ-mlv.fr]

> De: "Guy Steele" <guy.steele at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Kevin Bourrillion" <kevinb at google.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 14 Mars 2018 17:12:34
> Objet: Re: expression switch vs. procedural switch

>> On Mar 14, 2018, at 12:16 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>>> De: "Kevin Bourrillion" < [ mailto:kevinb at google.com | kevinb at google.com ] >
>>> À: "amber-spec-experts" < [ mailto:amber-spec-experts at openjdk.java.net |
>>> 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 < [ mailto:kevinb at google.com
>>> | 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.)

Do not introduce a feature in the language which is used once every year is a good start. 
Do not add a solution to solve the corner^2 case (the corner case of a corner case as Brian call it) in the language. 

> 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.

on the Human aspect of programming, publish an official language guideline and provides tools that enforce it like Google does with Java or golang (with go-fmt). 

> —Guy
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/2ad3a1ef/attachment-0001.html>