Re: [DISCUSS] Should RFCs for new functions include a userland polyfill/reference implementation?
| From: | Larry Garfield | Date: | Fri, 04 Sep 2026 14:47:05 +0000 |
| Subject: | Re: [DISCUSS] Should RFCs for new functions include a userland polyfill/reference implementation? | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132425@lists.php.net to get a copy of this message | ||
On Fri, Sep 4, 2026, at 9:23 AM, Tim Düsterhus wrote:
> Hi
>
> On 9/4/26 15:02, Larry Garfield wrote:
>> We stress over the performance impact of certain generics approaches, we spent a lot of
>> time thinking about performance implications for hooks, or PFA, or pipes. stdlib functions should
>> not be exempt from that consideration. They should just be considered appropriately and in context.
>
> Okay, let me spell out what was implied in my previous email:
>
> Performance considerations are asymmetric. If something is too slow,
> this is a problem and means that it can't ship. However this only
> affects the specific implementation - it is entirely possible to build a
> faster implementation of the feature in question based on the accepted
> semantics. Though in some cases the semantics inhibit a faster
> implementation - or make it hard to create one. These considerations
> obviously also apply to the stdlib functionality and not just language
> features.
>
> On the other side we would not ship something just because it’s fast.
100% agreed on this point.
> And that is also independent of whether it’s stdlib or a language
> feature (such as erased generics, which are fast, but have language
> design arguments against).
>
> Or in short: Performance is a property of the implementation, not a
> property of the feature.
>
> Best regards
> Tim Düsterhus
I think we're saying almost the same thing, from different directions. Performance alone is
not an argument for a feature, but can be a contributing factor. Performance alone MAY be an
argument against a feature, depending on the feature, but there are still many other factors to
consider.
So I restate my original point: When adding a function/class/thing to stdlib that *could* be
implemented in user-space (not everything can be), knowing the relative performance difference is a
useful data point to have, but it is not itself a decisive argument for or against the feature.
--Larry Garfield