Re: [rfc] str_mask function

در تاریخ دوشنبه Û²Û± سپتامبر ۲۰۲۶، Û°Û´:Û°Û´ Morgan <weedpacket@varteg.nz> نوشت: > On 2026-09-21 03:48, سپهر محمودی wrote: > > > > > > Just to clarify the intent: str_mask() is designed not as > > domain/ > > business logic (like slugification), but as a low-level string > > manipulation primitive—very similar to existing core primitives like > > str_pad(), FøÏ°¬ž˜ > > “ý¿v—bosubstr_replace(), and str_repeat(). > > > > The main reasons for considering it at the core level rather than > > userland/PECL are: > > 1. First-class integration with #[\SensitiveParameter] to > > ensure safe > > handling of sensitive/PII data in stack traces. > > 2. Providing a strict, fail-closed contract natively without the > > allocation and performance overhead of composing multiple userland calls. > > > See, this #[\SensitiveParameter] thing is what makes it look to me like > business logic rather than low-level; it assumes that what is being > masked is - well - sensitive, according to some criterion. There might > be other reasons why someone will want to mask part of a string that > _isn't_ sensitive (anyone for a game of Hangman?). > > It's reasonable to apply #[\SensitiveParameter] to the $password field > of openssl_password_hash() or PDO::connect() because you are by > definition passing a sensitive value (a password) in that parameter. But > for low-level string manipulation? Strings are arbitrary sequences of > bytes and "sensitivity" is not an inherent property of such things. > > > > Morgan > ---------- Hi Morgan, That is a very valid and fair point. The intention was to provide a helpful security default, but you are right: str_mask() is fundamentally a low-level string manipulation primitive, and masking is also used in non-sensitive contexts (like word games, anonymized identifiers, or formatting). Treating it as a generic string primitive without baking in domain-specific assumptions makes total sense. I will remove the #[\SensitiveParameter] attribute from the RFC to keep the function purely general-purpose, consistent with other ext/standard string functions. Thanks for the insightful feedback! Best regards, Sepehr