Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110288
Message-ID: <1040F01D-9A1F-4214-89B0-F5730114F033@benramsey.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_E4D92513-99E6-4F3A-8037-81A573576266";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 27 May 2020 11:52:21 -0500
In-Reply-To: <CANZOY=AHs40Dzo_G44Q9byDbJ7emu5yDpmBMTSQ2uCXSARG_Dw@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: Arnold Daniels <arnold.adaniels.nl@gmail.com>
References: <CANZOY=AHs40Dzo_G44Q9byDbJ7emu5yDpmBMTSQ2uCXSARG_Dw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Strict operators directive
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_E4D92513-99E6-4F3A-8037-81A573576266
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On May 15, 2020, at 17:03, Arnold Daniels =
<arnold.adaniels.nl@gmail.com> wrote:
>=20
> Hi all,
>=20
> I'd like to restart the discussion for the strict_opterators RFC (
> https://wiki.php.net/rfc/strict_operators).


I=E2=80=99m having trouble wrapping my head around this statement:

> To compare two numeric strings as numbers, they need to be cast to
> integers or floats.

As an example, the RFC shows:

    "100" =3D=3D "1e1";               // false
    (int)"100" =3D=3D (int)"1e2";     // true

But this is identical to how PHP works today.

I think the identity operator is more expressive in this case,
especially to show intent.

> The function of the =3D=3D=3D and !=3D=3D operators remains unchanged.

So, while `true !=3D 0` throws a TypeError, `true !=3D=3D 0` continues =
to
function as it does today, without a TypeError? I find this behavior
confusing and unintuitive.

I can see the value in what the RFC proposes (strict type comparisons),
but I think the behavior proposed still needs work. While I understand
it=E2=80=99s opt-in on a file-by-file basis, I don=E2=80=99t think =
changing the meaning
and behavior of existing operators is the right approach.

Maybe if we could introduce new comparison operator symbols? But I=E2=80=99=
m not
sure what those symbols would be.

Cheers,
Ben

--Apple-Mail=_E4D92513-99E6-4F3A-8037-81A573576266
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCXs6axQAKCRCwLZeYnIwH
Gx7YAP97b+lchN5Ij/cbGbZNxfG4IYSgSaUa3SyNM7tbgXJ0gwD/eZG4PsrYexiH
PuPx+bgqM5YBHXP5zYBfp+EY6pxDHYg=
=M4rO
-----END PGP SIGNATURE-----

--Apple-Mail=_E4D92513-99E6-4F3A-8037-81A573576266--