Re: Strict switch statements

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.ppv@gmail.com> wrote: >> >> On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon <pollita@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