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
