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.
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: http://www.php.net/unsub.php
