Hello, what about exposing a strict keyword option or a php ini option?
- NO - leave as it is default - YES - allow trailing whitespace punks - YES - disallow leading whitespace sane people On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel <benjamin.mo...@gmail.com> wrote: > What about going forward with the trailing whitespace RFC right now, but > ask to vote between 3 options? > > - NO - leave as it is > - YES - allow trailing whitespace > - YES - disallow leading whitespace > > And then proceeding with the string to number comparison RFC? > > Ben > > On Thu, 4 Apr 2019 at 01:15, 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. > > > > Andrea > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
