Re: Re: Adding explicit intent for SWITCH/CASE fall through?

At the case level, not the switch level. Here is the code that I was working on that caused me to finally send this message. switch ( $new_name ) { case 'portal_id': case 'portalid': $new_name = 'portalId'; break; case 'form_id': case 'formid': $new_name = 'formId'; break; case 'educationtype': $update = false; fallthrough; case 'education': $new_name = 'educationType'; if ( EducationTypes::is_edu_type_slug( $value ) ) { $new_value = EducationTypes\Names::get( $value ); } break; default: $update = false; break; } (Note the code is from an iterative refactoring process where I will eventually get rid of this specific code but in the short term I am trying to unify all the terms into a single list rather than have a bunch of different names in the code for the same thing. When iterative refactoring my emphasis is understanding the logic and on on unifying the code and not on what is the best architecture.) > It sounds like a job for a static analysis comment: > > /** @DisableSwitchStatementFallthroughWarning */ Interesting. That feels more like static analysis tools use the only tool they have — comments — since they can't change PHP, and not a good model for language evolution. My reaction is it feels rather inelegant. It would be a heck of a lot more to type and a good bit harder to read. In my perfect world it would be part of the language, not just a commenting convention. Is there a a standardized list of these for PHP somewhere on php.net? I googled and did not find any such list; maybe I am missing it? I doubt we would want an option in the future for PHP to generate a warning when this type of comment is missing? Key to this request is that PHP also generates a warning when warnings are turned on during development. Also, when reading code I tend to have "comment blindness" similar to how people have "ad blindness" when browsing the web. Since comments are typically not code and are often not maintained I don't trust them so only read comments when the code is hard to decipher. In this case if I saw a missing break I would assume the person intended it and might not realize there is a comment indicating it. But YMMV. > a token that would effectively no-op in all circumstances. Is it really a no-op? I envisioned is a jump to the next case. But I also saw that it was small enough scope I could probably use it to learn how to author a patch for PHP. BTW, GoLang has exactly what I am asking about: https://github.com/golang/go/wiki/Switch#fall-through -Mike > On Oct 17, 2019, at 5:42 PM, Mark Randall <marandall@php.net> wrote: > > On 17/10/2019 21:54, Mike Schinkel wrote: >> Additionally it could be added in 8.0 and then in 8.1 flagged with a warning when a CASE >> does not have one for the two, but only if people don't object to this. While I know some on >> this list feel strongly that warnings must come with to future plans to generate errors I would >> personally be 100% okay if it indefinitely generated only a warning. > > Would you put this at switch level, or case level? > > Unless your plan is to redefine how switch works by default, which would be quite ambitious, > I'm not sure it makes a great deal of sense to add a token that would effectively no-op in all > circumstances. > > It sounds like a job for a static analysis comment: > > /** @DisableSwitchStatementFallthroughWarning */ > switch ($x) { > case 1: > $x = doSomething(); > > case 2: > doLaLaLaLa(); > break; > > default: > doTralala(); > } > > -- > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >