Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105065
To: internals@lists.php.net
References: <40683e93-f8e9-5a8c-9646-31c73c99396f@fischer.name>
 <CAF+90c-cVBy=YaPVz5B2Ua26y_yBz5KRnx9BnjVGe6uHbsi2Bg@mail.gmail.com>
Date: Thu, 4 Apr 2019 01:15:44 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
MIME-Version: 1.0
In-Reply-To: <CAF+90c-cVBy=YaPVz5B2Ua26y_yBz5KRnx9BnjVGe6uHbsi2Bg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
From: ajf@ajf.me (Andrea Faulds)
Message-ID: <php.internals-105065@news.php.net>

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 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.

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 
“non-well-formed” numeric string, and I think this whitespace 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. ¯\_(ツ)_/¯

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