On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds <a...@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 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. >
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)? Regards, Nikita
