در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۱۷:۰۵ Pratik Bhujel < [email protected]> نوشت:
> Hi Sepehr, David, > > I checked the updated prior art, and I want to correct one thing from > my earlier objection: Laravel's Str::mask genuinely does converge on > the character/index/length shape (with an encoding parameter), and > CakePHP 5.4 now has Text::mask with essentially the same core > operation. So I don't think it would be fair to say there is no prior > art here. > > But that actually makes the remaining question sharper: what exactly > are we standardizing? > > Both Laravel and CakePHP are multibyte-aware, and both have behavior > that differs from the RFC's new fail-closed semantics. For example, > they can return the original string for ranges that do not select > anything, whereas the RFC now proposes ValueError for invalid > boundaries. If prior art is part of the justification, then PHP core > would not simply be standardizing that prior art; it would be > deliberately changing its contract. That may be the right choice, but > I think it needs to be justified separately. > > Also, #[SensitiveParameter] is useful, but it isn't a core-only > benefit. Userland functions can already annotate sensitive parameters > with it, so I don't think that by itself strengthens the case for > putting the operation in core. > > 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. > > I've said my piece, so unless the semantics or rationale changes > materially, I'll leave it there and let the rest of internals decide. > > Best regards, > Pratik Bhujel > > On Sun, 20 Sep 2026 15:08:53 +0200 (CEST), David Maye Kitenge > <[email protected]> wrote: > > 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 سپهر محمودی <[email protected]> escribió: > > > > در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۱۳:۵۲ سپهر محمودی <[email protected]> > نوشت: > > > > در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۰۴:۴۳ Pratik Bhujel < > [email protected]> نوشت: > > > > 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 > -------- Hi Pratik, Thank you for the fair follow-up and for acknowledging the prior art examples. To briefly address your points: 1. **Semantics & Fail-Closed:** While frameworks historically return the original string on out-of-bounds inputs, PHP 8+ core standard library functions consistently throw `ValueError` for invalid offsets/lengths (e.g., `substr()`). For sensitive operations like masking, throwing a `ValueError` ensures a strict fail-closed contract—preventing silent fallback where unmasked data might inadvertently pass through unnoticed. 2. **Clarification on `grapheme_mask()`:** To clarify: the RFC draft for `grapheme_mask()` was created in June as a design concept, but the revised C implementation / PR matching the updated fail-closed semantics has not been completed yet. I apologize for any confusion in phrasing earlier. I appreciate all your constructive feedback throughout this discussion. It has helped clarify the scope and trade-offs of the proposal. I agree we can leave the decision to internals. Best regards, Sepehr
