Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102278
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
Date: Fri, 15 Jun 2018 10:31:31 -0500
Message-ID: <2525476.IYyWTAfRZ0@vulcan>
In-Reply-To: <CY4PR18MB1048B912CC0A586015B2F626DE7C0@CY4PR18MB1048.namprd18.prod.outlook.com>
References: <CAESVnVqm3tVt53bQfxOpQcOMf_2fXhnu9y+42trTfv7zNMONHw@mail.gmail.com> <CAESVnVreLqL3YQZ-avCpSOEjhr-qBa3HVG_eRsUEH1XhrEFEVw@mail.gmail.com> <CY4PR18MB1048B912CC0A586015B2F626DE7C0@CY4PR18MB1048.namprd18.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4015572.ypmF5eeSWI"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] Strict switch statements
From: larry@garfieldtech.com (Larry Garfield)

--nextPart4015572.ypmF5eeSWI
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Friday, June 15, 2018 9:54:48 AM CDT Theodore Brown wrote:
> On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> > 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.
> > 
> > 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.
> 
> I really like this idea. It's similar to the `match` control flow operator
> in Rust: https://doc.rust-lang.org/book/second-edition/ch06-02-match.html.
> 
> One reason I almost never use the `switch` statement in PHP (besides the
> lack of strict matching) is that it's so verbose. Having to put a `break`
> keyword after every case to avoid fallthrough means that it almost always
> requires less code to use `if` statements instead.
> 
> To avoid confusion with union types, I think I would prefer commas between
> or conditions instead of a pipe character. Example:
> 
> ```
> match ($expr) {
>   "foo", "bar" => {echo 'expr is "foo" or "bar"';},
>   true => {echo 'expr is true';},
>   1 => {echo 'expr is 1';},
>   null => {echo 'expr is null';},
>   false => {echo 'expr is false';},
>   default => {echo 'expr is something else';},
> }
> ```

I'm not fully sold that anything is needed here, but if something is I would 
also very much favor a substantially more robust match statement a la Rust, 
Go, et al over some form of "pickiness flag" on the existing switch.  Syntax 
details TBD, but the benefit of a flag on switch seems minimal while the 
benefit of more robust type/pattern matching is potentially large.

That said, however, also bear in mind that "PHP is not $language": One of the 
big uses of match in Rust, as I understand it, is to force fully exploring the 
keyspace of an enum.  We of course don't have enums so that use case goes 
away.  Given the emphasis on polymorphism in OOP PHP over RTTI, are there 
enough non-enum, non-RTTI use cases for a robust match statement to justify 
its inclusion?

If so, then I'm down. :-)

--Larry Garfield
--nextPart4015572.ypmF5eeSWI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAlsj29MACgkQ4MMKwDFx
YXet2ggAkDNL7asRfZ9eEc+VyllayPv5UtQ6p2OKt+89+NJyC620gItuqzrWzXAf
wYbRAnEU7uLznN32g4SZnStv97a6+1YvWZ8FcHk3+T9YQ7wdaz7T/DL/BndgHUlX
N9rzTfZonO5p1J4ctM1YKXRN0CKLYyC/ENznquC7wBNVPTPYaRg4je2rXaAXqNVn
LHeLsqZ4/hTAhuV4Eqk9aFcxvRA7nBjcNgQf6/an3jEwYTnXIcpZaBPRuhn0X+QK
umq+kt/H49Hk3UhC/xtMg6GytWwQNxl1fDI46hw2d7WeFzQc+wyDLCXPEOohRRkQ
ksG1cuIn4vRFJYbk7KluAmZ1taE7gQ==
=LUlO
-----END PGP SIGNATURE-----

--nextPart4015572.ypmF5eeSWI--