Hi,
The "obvious optimization" mentioned in the RFC, assumes just removing a line of code. https://github.com/zendtech/php-src/blob/zend-jit/ext/opcache/Optimizer/zend_inference.c#L2900 This may prevent run-time checks for IS_UNDEF on each read of the corresponding argument variables. I've just checked the effect of the patch on https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit It makes 2% speedup on bench.php (3.5% less CPU instruction retired). Anyway, performance is not the main reason of fixing the existing WTF behavior. And we do vote, especially to make common decisions on questionable topics. Thanks. Dmitry. ________________________________ From: Joe Watkins <pthre...@pthreads.org> Sent: Monday, June 13, 2016 12:35:27 PM To: Anatol Belski Cc: Ferenc Kovacs; Rowan Collins; Joe Watkins; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable? Morning internals, As already explained, strictly following SemVer is not possible for a project the size of PHP, with a release process such as PHP has. Backward compatibility is important. Also important is the long term goals for PHP, or at least for this major version of PHP: The goal is to make Zend so efficient that generating machine code from user code becomes a deployable solution. I did request that the RFC were expanded with details about the optimizations this "feature" makes impractical, I did get an extended explanation in the discussion thread from Nikita, but the RFC was not updated by Dmitry, as requested. That's not to say that everything that makes an optimization possible should get a green light, there will almost certainly be things I/we vote no on because of BC concerns, but in this case, I see more value in the break than I see in retaining the "feature". I can be wrong, might be ... it doesn't really matter, the majority has spoken. It is only my concern that the change is documented properly. Cheers Joe On Mon, Jun 13, 2016 at 12:22 AM, Anatol Belski <a...@php.net> wrote: > Hi, > > > -----Original Message----- > > From: Ferenc Kovacs [mailto:tyr...@gmail.com] > > Sent: Sunday, June 12, 2016 10:48 PM > > To: Rowan Collins <rowan.coll...@gmail.com>; Anatoliy Belsky <a...@php.net > >; > > Joe Watkins <krak...@php.net>; Davey Shafik <da...@php.net> > > Cc: PHP Internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy > > enforceable? > > > > Hi, > > > > my interpretation is that no rfc with BC breaks should target a minor > version. > > Our interpretation(based on past decisions and mailing list discussion) > of BC > > break is changing any userland API except where we excplicitly stated > that the > > previous behavior is undefined (and we also allow extensions to be moved > to > > pecl, which from user POV can be a BC break but we allow that > explicitly). > > I see a trend with php 7.1 that people try to add everything which we > couldn't > > finish in 7.0 as it would be a complementary php 7.0 release, not a > standard > > minor release which should abide our release > > process( https://wiki.php.net/rfc/releaseprocess ). > > Let me summon Anatol as he was the 7.0 release manager and Joe and Davey > as > > they are the RMs for 7.1, let's see what do they think about this. > > > For 7.0 - it was a major version, so a bit more breaches were introduced. > Many of such cases were conditioned by the internal changes so were > unavoidable, but some were accepted intentionally. Still, my interpretation > is close to yours, Ferenc, and the release process RFC is what I always > refer to when making a decision. But, even with 7.0, every case was > evaluated individually. > > For example, there was (and is) the case with throwing exceptions in core > functions. While it would make sense for many cases, there was for one no > general green light from the community. For two, there was (and are) > several cases where a fatal error is unavoidable and an exception would be > hard to implement. Still some new functionality was accepted with throwing > exception in function by an explicit RFC after the feature freeze. Having > that allowed in general were a paradigm change, so several PRs were > rejected in that regard. > > Thus, some cases can be quite controversial. As for me, the most what > matters is - the API should be consistent, existing PHP scripts should > still be functional, as much as possible. Even if something looks like > making sense but would impede the adoption of a new version, it should be > at least thought twice. I would call it a "generic recipe", still it won't > be applicable for every single case. As striving to have everything BC free > is not always possible and would block the actual language development or > leave bugs open. While some cases can be solved by a simple discretion, > others require a broad consent which is reached using the RFC instrument. > > Regards > > Anatol > > > On Sun, Jun 12, 2016 at 6:42 PM, Rowan Collins <rowan.coll...@gmail.com> > > wrote: > > > > > tl;dr: > > > > > > - We have an RFC [too_few_args] about to pass that seems to break our > > > published Release Process. > > > - Is the vote invalid, or do we need to change the Process? > > > - The opinions of those who voted "Yes" are particularly requested. > > > > > > > > > Hi All, > > > > > > The RFC to Replace "Missing argument" warning with "Too few arguments" > > > exception [too_few_args] looks certain to pass (it currently stands at > > > 36:8 in favour), and contains the following: > > > > > > Backward Incompatible Changes: "The BC break in intended." > > >> > > > > Proposed PHP Version(s): "PHP 7.1" > > > > > > This appears to be in direct contradiction with the Release Process > > > RFC [releaseprocess] adopted in 2010, which states: > > > > > > "x.y.z to x.y+1.z ... Backward compatibility must be kept" > > >> > > > > > > There are two interpretations of this: > > > > > > 1) The policy in [releaseprocess] is binding, and the vote on > > > [too_few_args] is invalid. Either the results should be ignored, or > > > silently taken as acceptance of the feature in 8.0, and implementation > > > postponed. However, there is no provision in the RFC for enforcement, > > > and the RMs are explicitly denied such a role: > > > > > > "The roles of the release managers are about being a facilitator ... > > > But > > >> they are not: Decide which features, extension or > > >> > > > SAPI get in a release or not" > > > > > > 2) There is some reason that [releaseprocess] can be ignored in this > case. > > > However, there is no mechanism I can see in [releaseprocess], nor any > > > justification in [too_few_args] or on its associated mailing list > threads. > > > > > > > > > It is often argued that "No BC" is too broad, and thus unenforceable. > > > It is probably impossible to give a water-tight definition of what is > > > acceptable, but we can state some general principles. > > > > > > The Introduction to [releaseprocess] implies the following aim: > > > > > > - To ensure a smooth and predictable upgrade process between minor > > > releases. > > > > > > From this, I would consider the general spirit of the BC rule to be: > > > > > > - Any reasonably written PHP application which runs successfully under > > > PHP x.y.z should run successfully under PHP x.y+1.z without > > > significant modification. > > > > > > For instance, a program which runs fine under 5.3 may need invasive > > > changes to remove call-time pass-by-reference before it runs on 5.4; > > > preventing this seems to be the intent of the rule. > > > > > > > > > Here is where things begin to get subjective, but the following seem > > > reasonable to me, and seem to match most decisions made up until now: > > > > > > - Notices, Warnings, etc, may change severity, but must not become > > > Errors or Exceptions. > > > - An Error may be removed, or downgraded to a Warning, etc, if there > > > is good reason to do so, e.g. new behaviour gracefully handles a > > > previously unhandled case. (Many of the cases below boil down to > > > this.) > > > - The defined behaviour of operators must not change. > > > - New operators, or application of operators to new situations, may be > > > added, where such application would previously have been a error. > > > - New keywords, functions, and classes may be reserved in the global > > > namespace, because PHP "owns" this namespace. However, this must be > > > done with care, and following the naming guide. > > > - New arguments or type cases may be added to built-in functions. > > > - Old arguments must not be removed from built-in functions. > > > - Functions must not be removed, except for the special case of moving > > > a "bundled" extension to PECL, such that loading the PECL module > > > restores full compatibility. > > > - Accidental and undocumented behaviour ("bugs") may be changed if > > > some effort is made to demonstrate that it is not widely relied on. > > > - The above rules may be broken only with careful justification, e.g. > > > to remove a major security issue. > > > > > > Note that [releaseprocess] already states that justification must be > > > provided for BC breaks, even where it allows them: > > > > > > It is critical to understand the consequences of breaking BC, APIs or > > >> ABIs (only internals related). It should not be done for > > >> > > > the sake of doing it. > > > > RFCs explaining the reasoning behind a breakage and the consequences > > > along with test cases and patch(es) should help. > > > > > > > > > If the above set of rules were adopted as binding, the vote on > > > [too_few_args] would be invalid, because: > > > > > > - it promotes a warning to an error > > > - the behaviour it is changing is documented and long-standing > > > - it does not justify itself as a necessary exception to the rules > > > > > > I would be very interested to hear from those of you who voted "Yes" > > > on [too_few_args] as to how you would formulate the rules instead. > > > > > > > > > References: > > > [too_few_args] https://wiki.php.net/rfc/too_few_args > > > [releaseprocess] https://wiki.php.net/rfc/releaseprocess > > > > > > Regards, > > > > > > -- > > > Rowan Collins > > > [IMSoP] > > > > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > > > visit: http://www.php.net/unsub.php > > > > > > > > > > > > -- > > Ferenc Kovács > > @Tyr43l - http://tyrael.hu >
