Hello, Yes and No php has an existing echo-system of extensions which could not work without this ini model; therefor it's fashion trend which is in my opinion unrealistic or you are ready to break existing infrastructures.
Enforcing the right behavior (third one) will break existing code big time; hence at some point you need to go with a transitional state; it does not say that one day you'r not gonna retire it and finally enforcing only one ((the right behavior (third one))). On Thu, Apr 4, 2019 at 9:06 AM Benjamin Morel <benjamin.mo...@gmail.com> wrote: > 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 >>> > >>> > >>> >>
