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

Reply via email to