There is one other point I genuinely need clarified. Earlier in this
thread you wrote that you had not designed or implemented
grapheme_mask() yet. But there is already a Grapheme Mask RFC from
June under your name, currently marked "Under Discussion", with the
same offset/length model and an explicit note that str_mask() would
follow as a separate RFC. Did you mean that you have not implemented a
revised version? As written, those two statements do not line up.
So at this point I think the disagreement is fairly clear. There is
real prior art for a masking helper, which answers part of my earlier
question. What is still open is whether that helper belongs in core,
and whether the proposed semantics are the right ones when they
intentionally differ from the frameworks being cited as prior art.
I don't think another benchmark round resolves that API-design question.
Hey dear.
(I sent to you an email on Private without realising, I'm sorry for the duplication).
It is an interesting proposal. Although I have some issue with the proposal.
I'm not an internal contributor, so my opinion doesn't have anything to do with any RFC approval.
The str_mask function is something that, for sensitive data, is good for hiding. That's something done with payment providers such as stripe.
However, there are many useful functions that, even though useful, aren't included in an RFC. For example: a slugger/sluggify function. This is the most important component in CMS and template builders. For example: I'm creating a modular CMS as Symfony composer dependency. Routing of pages are dynamic, and require a page path that is a valid in a SEO perspective.
Would a slugify extension be useful? It would be as useful as a slugify composer package (to which point I use `uniqid` + a prefix for default slug, and then I just change it manually). I may create a C extension for that. However, does it need to be included inside a PHP internal? I don't think so. No need to. I can create and external package for that, and Install in every machine or docker image of PHP+ my extension.
I don't think business logic should be included in a programming language API. Furthermore, I think it should be as much atomic as possible so that other developers can build upon it. Look for PHP 8.5 with pipe operator "|>": this is actually the greatest invention I have seen. It is a very useful pattern that can be used to rewrite many hard to read program into a function-like code. Even the str_mark can be created as a function through it, and it would be perfectly fine.
From what I read, you don't need str_repeat . . . You can just use "****" of "XXXX" N times you need. That is something that is very dependent on a niche use case. I consider ecommerce niche, as not every single web developer (the purpose of PHP in the first place) are involved in ecommerce. It's sounds reasonable that PHP is done for developers to get creative and create their program. That's the reason libraries exist in the first place.
What about `uniqid` function, doesn't it look like `str_mark` dilemma? I don't think so: because creating unique IDs is something very necessary when you work with databases to ensure that every single object as a unique identifier. And not only that: I also use it for Server Side Rendering pages where an HTML component generated by PHP needs an autogenerated id tag (i.e: a carousel element with a unique identifier for JS code to handle it dynamically). And both use cases pass from niche to actually useful in any situation. The fact that you can add entropy is also an important supplement to the function. This logic also applies to cryptographic functions, maths function, data structures, SPL, and others. Because it is not only about use case (which is crucial), it is also about the difficulty to implement one from scratch, or use a PHP library for it.
Also, if Cake PHP needed an extension for it, I think they would first create a composer PHP package, else an extension to it. But creating an extension to avoid 2-3 function calls sounds excessive, knowing that not every single project needs to handle PII data (name, SSN, Credit Cards, etc). Also, when you handle Credit Cards, from what I know, most companies uses an external a payment provider that mask this information by default (maybe due to PII norms). So the use for credit card goes automatically discarded (unless you are a PII compliant payment provider, to which you still don't need an extension for a function that a PHP class can provide as a method, in case of Object Mapping classes).
So, I think it would be quicker and more productive for you to start as an individual extension, get it very well known, and then by the approval of several people, get it included later in a PHP RFC. Because I have seen many small packages and extensions that started as an independent project, and then included in the main API.
I also say it because honestly, it is very tiresome to open the mail Inbox, and read a conversation that goes near 15 threads, in which the starter of the thread goes back and forth explaining his point with somehow vague objectives, with some contradictions and stating facts that were not mentioned at the first place.
I'm not going against you. It is just that it is not convincing enough to add it into a main API of a PL. And I'm not saying that it is not useful, it is just that this can be done easily in many different ways. But I see your enthusiasm, and I think it would definitely go well if you created, let's say, an organisation that create useful extension outside the main API. Because adding such a small function doesn't look useful in a PHP8.* release page neither.
I don't want to be rude, I'm sorry if it sounds like it. It just looks like the conversation about the RFC is going nowhere.
Thanks for your attention,
David Maye
El 20/09/2026 13:02 سپهر محمودی <sepehrphpr@gmail.com> escribió:
در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۱۳:۵۲ سپهر محمودی <sepehrphpr@gmail.com> نوشت:
در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۰۴:۴۳ Pratik Bhujel <prateekbhujelpb@gmail.com> نوشت:
Hi Sepehr,
Thanks. I think we may be talking past each other slightly.
When I see major frameworks like CakePHP having to implement custom utility functions for simple tasks like string masking, it suggests that we are reinventing the wheel.
That shows that masking is a real use case, which I don’t dispute. What I’m still missing is evidence that this specific primitive is what those projects are repeatedly reinventing.
If CakePHP is part of the motivation, I think the strongest evidence would be to show an actual CakePHP implementation/use case that could be replaced by:
str_mask(string, mask_char, offset, length)
without changing its semantics. Even better would be a small prior-art section with several independent libraries/frameworks converging on roughly the same operation.
Otherwise, “frameworks implement masking” establishes the problem, but not necessarily this particular API as the abstraction PHP core should standardize.
The evidence for my point is available in my RFC.
I did read it. My concern is exactly the distinction above: evidence that masking exists is different from evidence that this API is the common missing primitive.
Assuming the recent semantic issues have now been addressed, this is the part I would focus on before implementation-level optimization. A concrete before/after from the cited real-world code would make the case much easier to evaluate.
Best regards,
Pratik Bhujel
----------
Hey Pratik,
Regarding the evidence for common usage: I've actually included a direct comparison and link in the RFC's "Motivation / Prior Art" section at the very end. It demonstrates how existing code patterns directly map to the proposed `str_mask()` signature.
Would be great if you could glance over it when you have a moment. Let me know if that addresses your point!
Best,
Sepehr