Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][Discussion] Grapheme Mask »

[RFC][Discussion] Grapheme Mask

php.internals

سپهر محمودی

67 days ago
Hi everyone, I’d like to start the discussion period for the Grapheme Mask RFC: https://wiki.php.net/rfc/grapheme_mask The RFC proposes `grapheme_mask()` for the Intl extension, with Unicode-aware masking based on grapheme cluster boundaries. Feedback is welcome over the next 14 days. Best regards, Sepehr

Ayesh - PHP.Watch

65 days ago
> I’d like to start the discussion period for the Grapheme Mask RFC: > > https://wiki.php.net/rfc/grapheme_mask > > The RFC proposes `grapheme_mask()` for the Intl extension, with Unicode-aware masking based on grapheme cluster boundaries. >
Hi Sepehr, Thank you for the work put into the RFC. **Opinion**: I agree that Grapheme is the right place for this function, but a `str_*` function would have improved its "natural discovery." Perhaps adding a `str_mask` in addition to the `grapheme_mask` makes more sense? **Suggestion**: I find the limitations of `$start` and `$length` too restrictive. Laravel's `Str::mask`[^1] for example offers more expressive control over the offset and length. Two of the more common string masking callsites are when you mask an email address while revealing the domain name and 1-2 characters of the username part, or showing only the last four characters of a payment card number. Because different use cases require different masking patterns, I think the proposed `grapheme_mask` function will not be an easy drop-in replacement. However, I think providing a built-in masking function in the language is a good move, not an unnecessary feature. [^1]: https://laravel.com/docs/13.x/strings#method-str-mask

Rowan Tommins [IMSoP]

65 days ago
On 28/06/2026 10:59, Ayesh Karunaratne wrote:
> **Suggestion**: I find the limitations of `$start` and `$length` too > restrictive. Laravel's `Str::mask`[^1] for example offers more > expressive control over the offset and length.
The only difference I can see is the use of a negative start parameter to count backwards from the end of the string. I agree that would be a useful addition, and consistent with other functions such as substr() and array_splice(). Are there other options that Laravel provides, or which you think could be provided? On the subject of consistency, it looks like other functions use $offset rather than $start, so we should be consistent with that - especially now we have named parameter calling. I'm not sure if there's a direct equivalent to $mask_char anywhere which we should match.
-- Rowan Tommins [IMSoP]

Nick

65 days ago
On 27.06.26 00:47, سپهر محمودی wrote:
> Hi everyone, > > I’d like to start the discussion period for the Grapheme Mask RFC: > > https://wiki.php.net/rfc/grapheme_mask > > The RFC proposes `grapheme_mask()` for the Intl extension, with > Unicode-aware masking based on grapheme cluster boundaries. > > Feedback is welcome over the next 14 days. > > Best regards, > Sepehr >
Hey Sepehr, in https://news-web.php.net/php.internals/131531 you said you would add `str_mask` to the proposal. Was there any blocker why you didn't do it? Cheers Nick Aside: your RFC has some formatting issues. To display the list items correctly you can add two spaces ("  ") before each asterisk (*).

Alex Pierstoval Rock

64 days ago
Le 26/06/2026 à 18:47, سپهر محمودی a écrit :
> Hi everyone, > > I’d like to start the discussion period for the Grapheme Mask RFC: > > https://wiki.php.net/rfc/grapheme_mask > > The RFC proposes `grapheme_mask()` for the Intl extension, with > Unicode-aware masking based on grapheme cluster boundaries. > > Feedback is welcome over the next 14 days. > > Best regards, > Sepehr > >
Hey there, thanks for this great proposal! (I would've definitely have needed this a few weeks ago... :D ) Just my 2cents: the "Proposed PHP Version(s)" section contains "PHP 8.4 or 8.5.", and should be updated and refer to PHP 8.6 instead.