Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109597
Message-ID: <5E37A931-9ED0-4CD9-9044-868A322BB6E5@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_57C9E0CC-3AAB-4AB0-B42B-711C6BF0535F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 12 Apr 2020 11:04:50 -0400
In-Reply-To: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
References: <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_57C9E0CC-3AAB-4AB0-B42B-711C6BF0535F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I love everything about this, except for one deal killer.

I love the use of =3D>.  And I love the blocks.=20
=20
Plus I love that it can fully replace switch because of how using switch =
can easily allow an developer's oversight to introduce subtle bugs.

The deal killer IMO is this:

"match was added as a keyword (reserved_non_modifiers). This means it =
can't be used in the following contexts anymore:

	=E2=80=A2 namespaces
	=E2=80=A2 class names
	=E2=80=A2 function names
	=E2=80=A2 global constants"

-Mike


> On Apr 11, 2020, at 8:16 PM, Ilija Tovilo <tovilo.ilija@gmail.com> =
wrote:
>=20
> Hi internals
>=20
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>=20
> Due to the feedback I decided to take the RFC in a slightly different
> direction. The main objections were:
>=20
> 1. It didn't behave like the traditional switch so it shouldn't use
> the switch keyword
> 2. It didn't fix type coercion
> 3. The RFC was poorly structured
>=20
> In hindsight I understand why I had a hard time writing the RFC. I
> tried making a case against the switch statement while really not
> addressing the switch statement at all. The new RFC proposes a match
> expression that fixes all the objections raised against the switch
> statement. Additionally, match arms can now contain statement lists
> which allows you to use the match expression anywhere the switch
> statement would have been used previously.
>=20
> While some people have suggested statement lists aren't necessary I
> don't think it makes sense to raise objections against the switch
> statement without offering an alternative.
>=20
> I also experimented with pattern matching but decided against it. The
> exact reason is described in the RFC.
>=20
> I'm now confident this is the right approach. I hope you will be
> happier with this proposal.
>=20
> Happy Easter!
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


--Apple-Mail=_57C9E0CC-3AAB-4AB0-B42B-711C6BF0535F--