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 سپهر محمودی <[email protected]> escribió: > > > > > > > > > > در تاریخ دوشنبه ۲۱ سپتامبر ۲۰۲۶، ۰۴:۰۴ Morgan <[email protected] > <mailto:[email protected]>> نوشت: > > 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 > > > >
