Re: [rfc] str_mask function

Hi Sepehr, I don’t think benchmarks actually answer the main objection being raised here. They can show that a dedicated C implementation is faster than composing substr_replace() and str_repeat(), but they cannot show that this operation deserves a permanent core API. Before optimizing it, I’d rather see evidence that the abstraction itself is common: for example, a corpus analysis of real PHP applications/frameworks showing how often this exact offset/length masking pattern occurs and what existing implementations look like. Otherwise we may just be benchmarking a convenience wrapper. Also, the current RFC still documents out-of-bounds offsets as returning the original string unchanged, despite your reply saying it was changed to fail-closed, and it still says a multi-byte $mask_char is silently reduced to its first byte. Those semantics should probably be made consistent first. And Jordi’s #[SensitiveParameter] point seems especially relevant if handling sensitive data is the primary motivation. So I think the order should be: demonstrate the use-case, settle the contract, then benchmark the implementation. Best regards, Pratik Bhujel