> > what about exposing a strict keyword option or a php ini option?
There is a trend right now towards avoiding the language to be dependent on php.ini options. I'm on board with this, and would personally strongly discourage introducing such an option, and enforce one of these options for everyone instead. On Thu, 4 Apr 2019 at 17:05, M. W. Moe <mo.mu....@gmail.com> wrote: > 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 >> > >> > >> >
