On 14 June 2018 at 09:35, Nikita Popov <nikita....@gmail.com> wrote: > On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon <poll...@php.net> wrote: > > > Just for casual discussion at this point: > > https://github.com/php/php-src/pull/3297 > > > > switch ($a) { > > case FOO: > > // Works exactly as current behavior. > > break; > > case == FOO: > > // Nearly identical, though not using the ZEND_CASE optimization. > > // Can probably make this equivalent to `case FOO`, but it felt > > like an interesting direction. > > break; > > case === FOO: > > // Only triggers if `$a === FOO`, no type juggling > > break; > > } > > > > Love it? Hate it? See obvious flaws? The implementation is just a > > rushed proof of concept, not something I've labored over, it may well > > have bugs. Certainly wouldn't target anything earlier than 7.4, if at > > all. > > > > I like the general idea here (switch with strict type comparison), but not > super fond of the particular syntax and implementation. > > I think if people want to use strict matching, they'll quite likely want to > have it on all cases. Something like "strict switch ($expr) {}" or "switch > strict ($expr) {}" or "switch (strict $expr) {}" or "switch ($expr) strict > {}" or "switch ($expr) { strict; }" or whatever would be preferable in that > case. >
For ages, I've had an idea along these lines kicking around. Like Nikita, I was assuming that all branches would want strict comparison or none, so was thinking of putting the operator at the top, something like "switch ($expr) use (===)". I figured it could then be extended so the "===" could be substituted for any binary operator; for instance, you could match values into ranges with "switch ($score) use (>=)". That said, I can see an attraction in a form with the operator on the branch, if operators other than "==" and "===" are supported; for the range example, it might be handy to have cases for ">= 50", "> 0", and "=== 0". I prefer reusing "===" in some way over the word "strict", even if no other operators are supported, because "strict" could mean a number of things - "strictly no fall-throughs", for instance - and I think that could cause confusion (people already expect "strict types" to mean more than it does). Regards, -- Rowan Collins [IMSoP]
