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
