Hi internals,
While reviewing various RFCs that introduce new functions, I noticed an
inconsistency: some authors include a userland polyfill (reference
implementation) in their RFCs, while others do not.
I wanted to open a discussion on whether we should strongly encourage RFC
authors to provide a PHP userland implementation when proposing new
standard library functions, where technically feasible.
Of course, I understand that this isn't possible for every new
function—especially those that interact with low-level OS APIs, memory
management, or internal engine features. However, for functions dealing
with arrays, strings, math, or general logic, I believe this has a couple
of major benefits:
- It clarifies the exact intended behavior, including edge cases and type
coercions, making the proposal easier to understand without diving into the
C implementation. - It immensely helps the community (e.g., the Symfony polyfill team) to
quickly and accurately port the function to older PHP versions once the RFC
is accepted.
Should we consider adding this as a standard recommendation (e.g.,
"Reference Implementation") in the official RFC template for applicable
functions?
I would love to hear your thoughts on this.
Best regards,
Sepehr
Hi internals,
While reviewing various RFCs that introduce new functions, I noticed an
inconsistency: some authors include a userland polyfill (reference
implementation) in their RFCs, while others do not.I wanted to open a discussion on whether we should strongly encourage
RFC authors to provide a PHP userland implementation when proposing new
standard library functions, where technically feasible.Of course, I understand that this isn't possible for every new
function—especially those that interact with low-level OS APIs, memory
management, or internal engine features. However, for functions dealing
with arrays, strings, math, or general logic, I believe this has a
couple of major benefits:
- It clarifies the exact intended behavior, including edge cases and
type coercions, making the proposal easier to understand without diving
into the C implementation.- It immensely helps the community (e.g., the Symfony polyfill team)
to quickly and accurately port the function to older PHP versions once
the RFC is accepted.Should we consider adding this as a standard recommendation (e.g.,
"Reference Implementation") in the official RFC template for applicable
functions?I would love to hear your thoughts on this.
Best regards,
Sepehr
Interesting idea. I think "recommended where relevant, but not required" is a reasonable policy to have. As noted, many RFCs don't have polyfillable features. For those where it is feasible, I think the "make it clear what the logic is" angle is the most compelling. (I often do that in the non-polyfill RFCs to help clarify the behavior.) And it would also give us a target to benchmark against to see if putting it in C really has a performance benefit.
--Larry Garfield
در تاریخ سهشنبه ۲۵ اوت ۲۰۲۶، ۱۹:۰۸ Larry Garfield larry@garfieldtech.com
نوشت:
Hi internals,
While reviewing various RFCs that introduce new functions, I noticed an
inconsistency: some authors include a userland polyfill (reference
implementation) in their RFCs, while others do not.I wanted to open a discussion on whether we should strongly encourage
RFC authors to provide a PHP userland implementation when proposing new
standard library functions, where technically feasible.Of course, I understand that this isn't possible for every new
function—especially those that interact with low-level OS APIs, memory
management, or internal engine features. However, for functions dealing
with arrays, strings, math, or general logic, I believe this has a
couple of major benefits:
- It clarifies the exact intended behavior, including edge cases and
type coercions, making the proposal easier to understand without diving
into the C implementation.- It immensely helps the community (e.g., the Symfony polyfill team)
to quickly and accurately port the function to older PHP versions once
the RFC is accepted.Should we consider adding this as a standard recommendation (e.g.,
"Reference Implementation") in the official RFC template for applicable
functions?I would love to hear your thoughts on this.
Best regards,
SepehrInteresting idea. I think "recommended where relevant, but not required"
is a reasonable policy to have. As noted, many RFCs don't have
polyfillable features. For those where it is feasible, I think the "make
it clear what the logic is" angle is the most compelling. (I often do that
in the non-polyfill RFCs to help clarify the behavior.) And it would also
give us a target to benchmark against to see if putting it in C really has
a performance benefit.--Larry Garfield
I'm really glad to see Larry's positive feedback. Looking forward to
hearing more thoughts from everyone else on this.
Best,
Sepehr
Hi Larry,
Thanks for the feedback!
I completely agree with the "recommended where relevant, but not required"
approach. Making it a strict requirement would be an unnecessary blocker
for features that simply can't be polyfilled.
Your point about benchmarking is spot on. Having a userland implementation
gives us a clear baseline to prove that the C implementation actually
offers a tangible performance benefit, which is often a key argument in
many RFCs. And as you mentioned, it acts as a perfect executable
specification to clarify the expected behavior.
Given this, do you think it would be worth adding a short note or
recommendation to the RFC HOWTO document? Just as a gentle encouragement
for future RFC authors to include a userland polyfill (or equivalent PHP
logic) when feasible.
Best regards,
Sepehr
در تاریخ سهشنبه ۲۵ اوت ۲۰۲۶، ۱۹:۴۴ سپهر محمودی sepehrphpr@gmail.com نوشت:
در تاریخ سهشنبه ۲۵ اوت ۲۰۲۶، ۱۹:۰۸ Larry Garfield larry@garfieldtech.com
نوشت:Hi internals,
While reviewing various RFCs that introduce new functions, I noticed an
inconsistency: some authors include a userland polyfill (reference
implementation) in their RFCs, while others do not.I wanted to open a discussion on whether we should strongly encourage
RFC authors to provide a PHP userland implementation when proposing new
standard library functions, where technically feasible.Of course, I understand that this isn't possible for every new
function—especially those that interact with low-level OS APIs, memory
management, or internal engine features. However, for functions dealing
with arrays, strings, math, or general logic, I believe this has a
couple of major benefits:
- It clarifies the exact intended behavior, including edge cases and
type coercions, making the proposal easier to understand without diving
into the C implementation.- It immensely helps the community (e.g., the Symfony polyfill team)
to quickly and accurately port the function to older PHP versions once
the RFC is accepted.Should we consider adding this as a standard recommendation (e.g.,
"Reference Implementation") in the official RFC template for applicable
functions?I would love to hear your thoughts on this.
Best regards,
SepehrInteresting idea. I think "recommended where relevant, but not required"
is a reasonable policy to have. As noted, many RFCs don't have
polyfillable features. For those where it is feasible, I think the "make
it clear what the logic is" angle is the most compelling. (I often do that
in the non-polyfill RFCs to help clarify the behavior.) And it would also
give us a target to benchmark against to see if putting it in C really has
a performance benefit.--Larry Garfield
I'm really glad to see Larry's positive feedback. Looking forward to
hearing more thoughts from everyone else on this.Best,
Sepehr