> De: "Guy Steele" <guy.ste...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Kevin Bourrillion" <kev...@google.com>, "amber-spec-experts" > <amber-spec-experts@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:fo...@univ-mlv.fr | >> fo...@univ-mlv.fr ] > wrote: >>> De: "Kevin Bourrillion" < [ mailto:kev...@google.com | kev...@google.com ] > >>> À: "amber-spec-experts" < [ mailto:amber-spec-experts@openjdk.java.net | >>> amber-spec-experts@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:kev...@google.com >>> | kev...@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
