Okay I have another question about the RFC in order to understand it's well.
There is no need to use string repeat function at all. If I want five hashtags, I can just do "#####", and everything is done 👍. Because I think people would add the str_repeat function if the data to mask has a very Dynamic length. But if we're talking about phone numbers, credit cards, they all have the same predefined length in the entire world (in the case of phone numbers, some uses 10 digits instead of nine. But even this can be fixed pretty easily without additional temporary send string). So if you do just like that, you are completely avoiding the use of intermediate zend string allocation. Just by replacing an operation with the correct mask, you get exactly the same result we've all needing to create a new global function. And (if I'm not wrong), if you want to implement a function called string mask, you can configure it in such way that it calls substring replace function without an additional Zend string allocation. And thinking about Cake PHP: if they use the kind of pattern that this RFC that tries to avoid, which is the use of intermediate zend string allocation just for a temporal buffer, then a pull request for that function optimization can be done following that kind of pattern (no string repeat needed) Because I think there is no need of very rigorous kind of testing just to check if some data will leak. No need to have that kind of safeguards prevents developers from "shooting on their foot" like in the case of developing in a language like C, just for masking that a a string. So my question is: you should use the correct string mask, with predefined set of characters, inside the substring replace function, then you don't need to string mask function right? Because the performance is nearly the same? Awesome a 30ms difference for this kind of operation that appears not very often, is it worth it? Considering the use of unnecessary string repeat? What the benchmark shows if you just don't use string replace? Kind regards, David Maye. > El 21/09/2026 13:27 سپهر محمودی <[email protected]> escribió: > > > > > > > > > در تاریخ دوشنبه ۲۱ سپتامبر ۲۰۲۶، ۱۳:۴۹ David Maye <[email protected] > <mailto:[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] <mailto:[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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
