Re: [rfc] str_mask function

Sorry from the last mail I meant Ensure, not injure. Grammatical character is on 😅. Sorry everyone > El 21/09/2026 12:15 David Maye <david.maye@seigisoft.com> escribió: > > > > > Hello dear Sepher. > > > So I have a question: > > > > 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 > > > Wasn't the objective of the RFC to have first class integration with > #[\SensitiveParameter]? > > > Also as you stated in that sentence, you want to injure handling of sensitive pii data in stack > trades. However that's kind of uses very uses as a very specific use case. But was he RFC first > design for that kind of use case? > > > Because it is kind of hard to understand it, the reason of the RFC, if in the same mails you > sent also you state that you are rectifying the RFC. It sounds like the RFC first is designed for a > very specific kind of use, which is very niche, and apart from that it is a very dynamically > designed RFC.. > > > It just I'm the kind of lost of why is the using in the first place. If you can do it in > user land perfectly. And in the case of using c, you have extensions that are not part of the main > API but solves a very important problem and issue. Why is the need in the main PHP API? Because it > sounds like you're trying just to push something into the main API just for the sake of pushing > it, and from each Mail the necessity of using it or it's consideration at least gradually > decreases > > > Kind regards, > > > David Maye > > El 21/09/2026 11:56 سپهر محمودی <sepehrphpr@gmail.com> > escribió: > > > > > > > > > > > > > > > > > > > > در تاریخ دوشنبه ۲۱ سپتامبر ۲۰۲۶، ۰۴:۰۴ Morgan > > <weedpacket@varteg.nz <mailto: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(), > > > > substr_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 > > > > > > > > >