Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104598
MIME-Version: 1.0
References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name>
In-Reply-To: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name>
Date: Wed, 6 Mar 2019 09:58:39 +0100
Message-ID: <CAF+90c-cVBy=YaPVz5B2Ua26y_yBz5KRnx9BnjVGe6uHbsi2Bg@mail.gmail.com>
To: Markus Fischer <markus@fischer.name>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000049cc7a05836933a2"
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000049cc7a05836933a2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 6, 2019 at 7:41 AM Markus Fischer <markus@fischer.name> wrote:

> Hello,
>
> On 06.03.19 01:16, Andrea Faulds wrote:
> > https://wiki.php.net/rfc/trailing_whitespace_numerics
> >
> > I expect this should be an uncontroversial proposal, but maybe I'm
> > jinxing it there. I hope you all like it. :)
> >
> > Thanks to Nikita for reminding me it existed and thus motivating me to
> > pick it up again. Also thanks to Nikita for suggesting a potential
> > follow-up RFC, and also making the =E2=80=9CSaner string to number comp=
arisons=E2=80=9D
> > RFC, both providing additional impetus for me to finally clean this up
> > and put it to discussion.
>
> Hmm, my first reaction would be the opposite.
>
> For all the changes which happened during the years, PHP got stricter;
> this would make it more lax.
>
> I know this is totally not the goal of the RFC, by my feeling is if we
> would change something (ignoring BC break for a sec) that it would be to
> actually _remove_ support for leading whitespace =F0=9F=A4=B7=E2=80=8D=E2=
=99=80=EF=B8=8F
>
> - Markus
>

I'm always a fan of making things stricter, but think that in this
particular case there are some additional considerations we should keep in
mind.

1. What is more important to me here than strictness is consistency. Either
both "   123" and "123   " are numeric, or neither are. Making "123    "
numeric is a change we can easily do, because it makes the numeric string
definition more permissive and is thus mostly backwards compatible. Doing
the reverse change is certainly not compatible and will be a much harder
sell.

2. I believe that a large part of the motivation here is that by making the
numeric string definition slightly more lax (in a consistent manner), we
can make *other* things more strict, because this essentially eliminates
the only "somewhat reasonable" case of trailing characters. The RFC already
mentions two of them:

a) We can hard reject "123foo" inputs to "int" arguments (and some other
places). Currently this is allowed with a notice. I think if we resolve the
trailing whitespace question, then there cannot be any reasonable
opposition to this change.
b) My own RFC on number to string comparisons would benefit from this. From
initial testing it has surprisingly little impact, but one of the few cases
that turned up was this comparison with a string that had trailing
whitespace.

Personally I think both of those changes are a lot more valuable than a
stricter numeric string definition without leading/trailing whitespace.

Regards,
Nikita

--00000000000049cc7a05836933a2--