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
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.
Suggestion: I find the limitations of
$startand$lengthtoo
restrictive. Laravel'sStr::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]
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 (*).
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.