Re: [rfc] str_mask function

Hi Sepehr, I have a few concerns with the current semantics before this becomes another permanent global API. The RFC motivates str_mask() primarily around sensitive data and privacy, but the proposed behavior is fail-open: str_mask('AB', '*', 3) === 'AB' An incorrect offset therefore returns the original sensitive value unchanged. If masking is being presented as the reason for introducing the function, why is an invalid masking range considered successful rather than exceptional? Silently leaking the input seems like a particularly surprising contract for an API whose stated purpose is hiding data. There is a similar issue with $mask_char. The signature accepts string, but the RFC specifies that only the first byte is used. So: str_mask($value, '●', ...) does not mask using the character that was passed. It takes one byte from a multibyte UTF-8 sequence and can produce invalid UTF-8. I understand that str_mask() is intended to be byte-oriented, but then accepting an arbitrary string and silently truncating it to one byte feels like the wrong API. Why not require exactly one byte and throw ValueError otherwise? My larger concern, though, is whether the primitive itself earns a place in core. The RFC's email example still needs strpos() and strlen() to determine where the semantic part to hide actually is. Credit cards, emails, phone numbers, tokens and identifiers all have different disclosure rules. PHP cannot determine those rules; the caller still has to do that work. Once the caller already knows the offset and length, the remaining operation is essentially replacement of a substring with a repeated byte. So I think there are three questions that need stronger answers: 1. What recurring capability does str_mask() provide that cannot already be expressed clearly with existing string primitives? 2. Do we have evidence from real-world codebases that this pattern occurs frequently enough to justify another global function rather than a small userland abstraction? 3. The RFC states that the implementation is "significantly faster". Could you include reproducible benchmarks against an equivalent substr_replace()/str_repeat() implementation, including short strings representative of the examples in the RFC? For operations on strings this small, C being faster in isolation does not necessarily establish that the difference is meaningful enough to justify expanding the standard library. I would also avoid describing this as providing privacy or GDPR compliance. Whether exposing part of an identifier is appropriate is contextual, and a generic byte-level replacement operation cannot provide that guarantee. I think these questions should be resolved before discussing the implementation itself. Best regards, Pratik Bhujel >