Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105170
MIME-Version: 1.0
References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name>
 <CAF+90c-cVBy=YaPVz5B2Ua26y_yBz5KRnx9BnjVGe6uHbsi2Bg@mail.gmail.com>
 <5ca53eb4.1c69fb81.e223b.922eSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c8zHTx0f+nb+MBX0=eZus8fi9+fjZq8EYMVfE=xMGTPCg@mail.gmail.com> <alpine.DEB.2.21.1904091156040.11325@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.21.1904091156040.11325@singlemalt.home.derickrethans.nl>
Date: Tue, 9 Apr 2019 13:06:01 +0200
Message-ID: <CAF+90c-0RvViQs5xZwhy-4ZGyWZi2Qj-Op742-rG6N6VZKmE2Q@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000030fc78058616f1d4"
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000030fc78058616f1d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 9, 2019 at 12:57 PM Derick Rethans <derick@php.net> wrote:

> On Tue, 9 Apr 2019, Nikita Popov wrote:
>
> > On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds <ajf@ajf.me> wrote:
> >
> > > I'm kinda unsure how to go forward because of these points. I would
> like
> > > to see improved comparisons, and I would like to see the end of the
> > > =E2=80=9Cnon-well-formed=E2=80=9D numeric string, and I think this wh=
itespace RFC could
> > > be helpful to both. But I can't see the future, I don't know whether
> > > people will vote for removing leading or permitting traiing whitespac=
e
> > > and whether or not they will be influenced by or this will influence
> > > opinion on the further improvements. =C2=AF\_(=E3=83=84)_/=C2=AF
> > >
> > > I'm torn between:
> > >
> > > * Vote on allowing trailing whitespace
> > > * Vote on disallowing leading whitespace
> > > * Vote on which of those two approaches to go for
> > > * Trying to bundle everything together and voting on it as a package.
> > >
> > > I'm probably thinking too strategically.
> > >
> >
> > Given the response on the mailing list (and also other places like
> Reddit),
> > it seems like people feel pretty strongly that it's better to drop
> support
> > for leading whitespace than add support for trailing whitespace. If we =
do
> > this, I think we should couple this change with the removal of "non
> > well-formed numeric strings", because they are so closely related (one
> > change would forbid leading whitespace and the other trailing
> characters).
> >
> > One possible course of action would be:
> >
> > a) In PHP 7.4 throw a deprecation warning in is_numeric_string if there
> is
> > leading whitespace (always).
> > b) In PHP 7.4 throw a deprecation warning in is_numeric_string if there
> are
> > trailing characters in mode 1 (mode -1 already throws a notice and 0
> > already treats as non-numeric).
> > b) In PHP 8.0 treat leading whitespace as non-numeric (always).
> > c) In PHP 8.0 treat trailing characters as non-numeric (always),  and
> > remove the non well-formed distinction (mode -1).
> >
> > Notably this also affects (int) behavior in that (int) "   42" will be =
0
> > and (int) "42xyz" will be 0.
> >
> > A less aggressive alternative would be:
> >
> > a) In PHP 7.4 throw a deprecation warning in is_numeric_string if there
> is
> > leading whitespace (unless mode is 1).
> > b) In PHP 8.0 treat leading whitespace as non-numeric (unless mode is 1=
).
> > c) In PHP 8.0 treat leading characters as non-numeric (unless mode is 1=
).
> > Remove non well-formed distinction (mode -1).
> >
> > This would keep the behavior of (int) as-is and only affect implement
> > numeric string checks.
> >
> > This discussion how mostly been around the implicit cases, what do peop=
le
> > think about the desired behavior of (int)?
>
> I think there should be no difference in behaviour between implicit and
> explicit cases.


I should probably clarify what I mean by explicit and implicit here. By
explicit I mean anything using (int) casts or doing so internally
(implicitly ^^) -- this *must* produce an integer in some way and does not
have the option of rejecting the input. By implicit I mean other places
checking for numeric strings, such as "int" parameters. These *do* have the
option of rejecting the input. Both cannot work the same way due to the
different constraints.

So to rephrase my question: While I think there is a consensus that
"123xyz" and "   123" should not be accepted by an "int" parameter, it is
not clear to me that there is also a consensus that (int) "123xyz" and
(int) "   123" should result in 0 rather than 123.

Regards,
Nikita

--00000000000030fc78058616f1d4--