در تاریخ دوشنبه ۲۱ سپتامبر ۲۰۲۶، ۱۳:۴۹ David Maye <[email protected]> نوشت:
> 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 > > ------- Hi David, Thanks for bringing this up — it's a completely fair observation. You and Morgan are spot on. Having `#[\SensitiveParameter]` in the initial signature was conflating two separate concerns: a core string primitive versus the caller's business context. Sensitivity is a property of the data being passed, not an intrinsic property of a byte-masking utility. I have updated the RFC accordingly and removed `#[\SensitiveParameter]` from the proposed function signature: https://wiki.php.net/rfc/str_mask This keeps the RFC laser-focused on what `str_mask()` truly aims to be: a clean, low-level string manipulation primitive. The core justification remains unchanged: 1. Performance & Zero Intermediate Allocations: In userland, achieving safe masking requires composing `substr_replace()` and `str_repeat()`, forcing intermediate allocations and buffer copying. A native C implementation operates directly within the buffer with zero intermediate overhead — which matters significantly on high-throughput paths like payload anonymization and access logging. 2. Predictable, Fail-Closed Semantics: Existing userland helpers handle boundary conditions inconsistently. By introducing a native primitive that adheres strictly to PHP 8+ conventions (such as standard `ValueError` semantics for out-of-bounds offsets, identical to `substr()`), framework authors and libraries gain a single, reliable building block rather than maintaining disparate implementations. Refining proposals based on community pushback is an essential part of this process, and stripping the attribute sharpens the focus entirely onto performance and language consistency. Best regards, Sepehr > >
