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
