Hi
On 2026-07-14 19:11, Holly Schilling wrote:
correct me if I'm wrong, but I don't see why that would be a RFC.
(Small) internal changes with no change in userland don't go through
the RFC process and are handled on GitHub instead. This should also
target the supported version (8.4) instead of master.
Honestly, I don’t know the norms for this kind of thing. This is a
small change, but it involves an ABI breaking change. That was why I
thought it should target a new release chain (8.6) rather than applying
it to 8.4. If anyone wants to help me steward this out of being a
draft, I would welcome the advice.
Even if there would be no change in internal API / ABI, performance
improvements are considered a feature and thus not applicable to PHP
8.4. Thus master / PHP 8.6 is the correct choice. With regard to an RFC,
please note that it’s less than 4 weeks until soft freeze, so it’s
impossible to meet the deadline with the minimum 2 weeks of discussion
and 2 weeks of vote. See also:
https://news-web.php.net/php.internals/131877
But I agree with the others that a pure performance improvement, without
an effect on the observable userland behavior (except for “it's faster
now”), very likely doesn't need an RFC - and probably not even a mailing
list discussion, unless there is disagreement on the PR itself.
Best regards
Tim Düsterhus
