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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
