On Tue, Apr 9, 2019 at 12:57 PM Derick Rethans <der...@php.net> wrote:
> On Tue, 9 Apr 2019, Nikita Popov wrote: > > > On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds <a...@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 > > > “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. > > > > > > > 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 people > > 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
