Sara Golemon – Thu, 14. June 2018 16:50
> On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov <nikita....@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
