Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110774
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <CAFPFaMK2ku+Jicv2znPnOb7RUQRc8iyVxRNOzjxRRmZh04RB2A@mail.gmail.com>
Date: Mon, 29 Jun 2020 14:53:53 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A3CDC880-BF7D-47EB-A3D3-63037C543E15@gmail.com>
References: <CAFPFaMK2ku+Jicv2znPnOb7RUQRc8iyVxRNOzjxRRmZh04RB2A@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Subject: Re: [PHP-DEV][RFC] Saner numeric strings
From: claude.pache@gmail.com (Claude Pache)


> Le 29 juin 2020 =C3=A0 12:30, G. P. B. <george.banyard@gmail.com> a =
=C3=A9crit :
>=20
> Greetings internal,
>=20
> While reviving the "Permit trailing whitespace in numeric strings" RFC =
[1]
> I didn't see Nikita's comment on Andrea's original PR which commented =
on
> the fact that we should get rid of the "leading-numeric string" =
concept.
>=20
> Therefore, mostly due to time constraints, I've merge the trailing
> whitespace RFC with the removal of this concept in the following RFC:
> https://wiki.php.net/rfc/saner-numeric-strings
>=20
> The main gist is to convert all E_NOTICEs  =E2=80=9CA non well formed =
numeric value
> encountered=E2=80=9D to the usual E_WARNING =E2=80=9CA non-numeric =
value encountered=E2=80=9D and
> allow trailing whitespaces, which would be most reasonables cases =
where the
> E_NOTICE has been emitted.
>=20
> This RFC is heavily based on Andrea's original RFC [1] and I would =
like to
> thank her once more for the preliminary work she's done that I could =
reuse.
>=20
> Best regards
>=20
> George P. Banyard
>=20
> [1] https://wiki.php.net/rfc/trailing_whitespace_numerics


Hi,

It is not clear for me, by reading the RFC, whether or not the behaviour =
of either implicit or explicit conversion of so-called leading numeric =
string will be preserved, beyond some Notices that will be converted to =
Warnings in the implicit case. For example, does (int) "2px" still =
produce 2, even when the string is now considered as non-numeric?

I think it is important to make sure that the current results of casting =
to int/float will not change. For example, I can imagine some script =
that reads a CSS value like "2px" and does some calculation on it, =
converting it to a number on the process. A Warning instead of a Notice =
will prompt the programmer to add explicit casts, which is probably a =
good thing. But changing the casted value to 0 would lead to bugs that =
are (1) harder to detect especially if the program already uses explicit =
casts, and (2) harder to correct.

=E2=80=94Claude