Apologies - sending again from on-list address. I’m not overly fond of the `case ===`
Could it be simply `case` for current behaviour and `strict case` for the new behaviour? I’d argue that while fall through can cause problems it also has legitimate uses. Sent from my iPhone Sent from my iPhone >> On 14 Jun 2018, at 15: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. > > Additionally, switch has the issue of fall-through behavior, which is > somewhat unexpected and error prone to many people. It might make sense to > introduce an entirely new "match" statement that conforms a bit more with > how switch-like strictures are implemented nowadays. That is, something like > > match ($expr) { > "foo" => {...}, > "bar" | "baz" => {...}, > } > > or similar. This might need some more design work to ensure forward > compatibility with potential future algebraic datatypes etc. > > Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
