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: php.internals: [PHP8.6] Soft feature freeze in 4 weeks
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