Re: Strict switch statements

Sara Golemon – Thu, 14. June 2018 16:50 > On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > > 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: > 1. Avoid adding new reserved symbols/keywords. > 2. 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. match is also used to destructure things in other language (at least in Rust). I d'like to to that: $a = [1, 2]; match ($a) { [2, $n] => { ... } [$m, $n] => { ... } [$m, $n, $o] => { ... } [$m, $n, $o, ...$next] => { ... } [] => {...} [$m] => {...} $l =>{...} } and I'm probably dreaming but if I could destructure objects it would be awesome: class User { public $id; public $banned; } $user = $repository->getById($id); // with https://github.com/hoaproject/Option // eg: $user = Some(new User($id, $banned)); // or: $user = None() match ($user) { Some:$user=User:{banned => true} => { assert($user instanceof User); /* user is banned */ } Some:User:{name=$name, banned => $banned, role='admin'} => { assert(!$banned) } Some:$user => { assert($user instanceof User); assert(!$user->banned) } None => { /* user not found */ } } It could also be used to match http Request, Json API input, etc. > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: www.php.net/unsub.php