Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112529
Message-ID: <19FFF24D-3B1E-40FA-B836-9229E95416EE@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6BB776CC-150C-4720-8D8B-AA6E5FD67FF3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 16 Dec 2020 11:54:02 -0500
In-Reply-To: <cd0664b2-b9d2-437d-ae8a-8963add56dc1@www.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <b6e84a3b-012e-4ef3-8c2b-14c7fcf2d45d@www.fastmail.com>
 <CAF+90c-WLa9V17ahpipY86vqMWWcG2K3znHuk6oAVkXAN000+Q@mail.gmail.com>
 <cd0664b2-b9d2-437d-ae8a-8963add56dc1@www.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Short-match
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_6BB776CC-150C-4720-8D8B-AA6E5FD67FF3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Dec 15, 2020, at 12:18 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Tue, Dec 15, 2020, at 3:00 AM, Nikita Popov wrote:
>> On Mon, Dec 14, 2020 at 6:34 PM Larry Garfield =
<larry@garfieldtech.com>
>> wrote:
>>=20
>>> I present to Internals this tiny RFC to follow up on the match()
>>> expression RFC from earlier in the year.  There was solidly positive
>>> support for this shortcut previously but it was removed for =
simplicity at
>>> the time, with the intent to bring it back later.  It's now later.
>>>=20
>>> https://wiki.php.net/rfc/short-match
>>>=20
>>> --
>>>  Larry Garfield
>>>  larry@garfieldtech.com
>>>=20
>>=20
>> Just like Sara, I'm not strongly opposed to this, but I'm also not =
sure
>> this is worthwhile. Writing "match (true) {" instead of "match {" is =
not
>> particularly tedious when compared to the size of the remaining =
structure.
>> Writing "match (true) {" has the advantage of being more explicit =
about
>> what this actually does, namely a "true =3D=3D=3D" comparison. If it =
is omitted,
>> a reasonable person might think that
>>=20
>>    match {
>>        preg_match(...) =3D> ...
>>    }
>>=20
>> is going to do something sensible, like it would if placed inside an
>> "if()". But it does not, as preg_match() returns 1, not true, and as =
such
>> the match arm will never be taken. This is more obvious when the =
value that
>> is being compared against is explicitly given.
>>=20
>> Of course, with "match {" being a dedicated syntax, we could make it =
a
>> TypeError to use a non-bool match arm...
>>=20
>> Regards,
>> Nikita
>=20
> Hm.  preg_match() is the first example I've seen that makes me think =
the weak comparison may have value in this case.  I will have to =
consider that and discuss with Ilija a bit.  (Since match was his =
addition and relates to the ongoing enum work.)  I'd also have to figure =
out how best to handle that, too, since it's a deeper change.  Whee!
>=20
> Several people have mentioned also short-circuiting switch the same =
way.  I am not opposed, and honestly don't feel too strongly about it =
either way.  On Twitter, someone suggested also short circuiting while =
(true) the same way; I don't know how useful that is, but I acknowledge =
the consistency argument.  I'm happy with whatever the consensus is on =
both points.

Allowing "switch {...}" to represent  "switch (true){...}" might not =
actually be consistent. Since switch/case does a loose equality check =
some people get confused when using it with booleans:=20

=
https://stackoverflow.com/questions/8829229/why-switchtrue-in-php-with-a-s=
trange-logic =
<https://stackoverflow.com/questions/8829229/why-switchtrue-in-php-with-a-=
strange-logic>

If we allow "switch {...}" to represent  "switch (true){...}" then the =
value switch compares will be hidden and less obvious to a developer if =
they are forgetting to consider switch's evaluation behavior. For some =
people this would increase the WTF factor.

#fwiw

-Mike

P.S.  OTOH allowing "while(true){...}" to be represented as "while{...}" =
would be great since AFAIK "while{...}" would not violate the principle =
of least surprise.


--Apple-Mail=_6BB776CC-150C-4720-8D8B-AA6E5FD67FF3--