Sorry from the last mail I meant Ensure, not injure. Grammatical character is
on 😅. Sorry everyone > El 21/09/2026 12:15 David Maye
<[email protected]> 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 سپهر Ù…Øمودی <[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
> >
> >
> >
> >
>
