> > 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.
Why? Wouldn't it be nice to align the behaviour of implicit and explicit casting, so that (int) "abc" throws a TypeError? Ben On Tue, 9 Apr 2019 at 13:06, Nikita Popov <nikita....@gmail.com> wrote: > 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 >
