I like the general idea here (switch with strict type comparison), but not

super fond of the particular syntax and implementation.

No arguments there. What's presented is "best I could come up in the bath". :)

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.

Agree that it's more likely to be all-or-not within a switch block.

If I could step through my thinking in putting it on the case

statement however, I applied two starting rules:

Avoid adding new reserved symbols/keywords. Try to make it read naturally.

I actually did consider Rowan's suggestion switch (expr) use (===) {} , but I didn't feel like it satisfied #2 well.

Instead, I chose to think of the T_CASE as a placeholder for the

switch expression. If you visually substitute the expression where

the 'case' is at, then this:

switch ($x) {

case === 1:

case === 2:

}

Could be read as:

switch (...) {

$x === 1:

$x === 2:

}

Not saying that's the only route, just walking through how I would

imaging it reading to new eyes.

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.

That's certainly more ambitious, but since we're just casually

talking, then let's explore it.

I like the idea of a richer syntax for matching that goes beyond

simple equality/identicality, but we'll need to think very carefully

about interactions (for example, in your example, is "bar" | "baz" a

bitwise binary OR?) What might default look like here? I guess we

still reuse the default keyword. My nit-pick about the "match" keyword

is that I (personally, and this is probably minority) think of this

like regex related.

I'll be honest, I didn't realize the fall-through behavior was a

learning curve issue. This block scoping would address that, but I

wonder if we could make use of break/continue. The former's meaning

being obvious enough, the latter allowing us to either fall through to

the next case or possibly continuing evaluating conditionals.

?

-Sara