Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102259
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.65 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c-HGB-2MbdrCYuQNrNYR4EJ9hAeFaKTW-sh1kwboDd0Kg@mail.gmail.com>
References: <CAESVnVqm3tVt53bQfxOpQcOMf_2fXhnu9y+42trTfv7zNMONHw@mail.gmail.com>
 <CAF+90c-HGB-2MbdrCYuQNrNYR4EJ9hAeFaKTW-sh1kwboDd0Kg@mail.gmail.com>
Date: Thu, 14 Jun 2018 10:48:57 -0400
Message-ID: <CAESVnVreLqL3YQZ-avCpSOEjhr-qBa3HVG_eRsUEH1XhrEFEVw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Strict switch statements
From: pollita@php.net (Sara Golemon)

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 no=
t
> 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 "switc=
h
> strict ($expr) {}" or "switch (strict $expr) {}" or "switch ($expr) stric=
t
> {}" or "switch ($expr) { strict; }" or whatever would be preferable in th=
at
> 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 (=3D=3D=3D)
{}`, 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 =3D=3D=3D 1:
  case =3D=3D=3D 2:
}

Could be read as:

switch (...) {
  $x =3D=3D=3D 1:
  $x =3D=3D=3D 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 t=
o
> introduce an entirely new "match" statement that conforms a bit more with
> how switch-like strictures are implemented nowadays. That is, something l=
ike
>
> match ($expr) {
>     "foo" =3D> {...},
>     "bar" | "baz" =3D> {...},
> }
>
> 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.

=F0=9F=A4=94
-Sara