Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105068
MIME-Version: 1.0
References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name>
 <CAF+90c-cVBy=YaPVz5B2Ua26y_yBz5KRnx9BnjVGe6uHbsi2Bg@mail.gmail.com> <5ca53ea8.1c69fb81.d773b.1df3SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5ca53ea8.1c69fb81.d773b.1df3SMTPIN_ADDED_MISSING@mx.google.com>
Date: Thu, 4 Apr 2019 10:57:31 +0200
Message-ID: <CAG9XoMT76XZFx6fKPMea0rdJpb6JB1Yzr7mHc6e-E5W4-vL3RQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004393a20585b09001"
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: benjamin.morel@gmail.com (Benjamin Morel)

--0000000000004393a20585b09001
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

What about going forward with the trailing whitespace RFC right now, but
ask to vote between 3 options?

- NO - leave as it is
- YES - allow trailing whitespace
- YES - disallow leading whitespace

And then proceeding with the string to number comparison RFC?

Ben

On Thu, 4 Apr 2019 at 01:15, Andrea Faulds <ajf@ajf.me> wrote:

> Nikita Popov wrote:
> > 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 stri=
ng
> > definition more permissive and is thus mostly backwards compatible. Doi=
ng
> > the reverse change is certainly not compatible and will be a much harde=
r
> > 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), w=
e
> > can make *other* things more strict, because this essentially eliminate=
s
> > 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 othe=
r
> > 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.
>
> 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 whites=
pace 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 whitespace
> 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.
>
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0000000000004393a20585b09001--