در تاریخ جمعه ۱۸ سپتامبر ۲۰۲۶، ۲۲:۲۳ Pratik Bhujel <
[email protected]> نوشت:
> Hi Sepehr,
>
> I have a few concerns with the current semantics before this becomes
> another permanent global API.
>
> The RFC motivates str_mask() primarily around sensitive data and privacy,
> but the proposed behavior is fail-open:
>
> str_mask('AB', '*', 3) === 'AB'
>
> An incorrect offset therefore returns the original sensitive value
> unchanged.
>
> If masking is being presented as the reason for introducing the function,
> why is an invalid masking range considered successful rather than
> exceptional? Silently leaking the input seems like a particularly
> surprising contract for an API whose stated purpose is hiding data.
>
> There is a similar issue with $mask_char.
>
> The signature accepts string, but the RFC specifies that only the first
> byte is used. So:
>
> str_mask($value, '●', ...)
>
> does not mask using the character that was passed. It takes one byte from
> a multibyte UTF-8 sequence and can produce invalid UTF-8.
>
> I understand that str_mask() is intended to be byte-oriented, but then
> accepting an arbitrary string and silently truncating it to one byte feels
> like the wrong API. Why not require exactly one byte and throw ValueError
> otherwise?
>
> My larger concern, though, is whether the primitive itself earns a place
> in core.
>
> The RFC's email example still needs strpos() and strlen() to determine
> where the semantic part to hide actually is. Credit cards, emails, phone
> numbers, tokens and identifiers all have different disclosure rules. PHP
> cannot determine those rules; the caller still has to do that work.
>
> Once the caller already knows the offset and length, the remaining
> operation is essentially replacement of a substring with a repeated byte.
>
> So I think there are three questions that need stronger answers:
>
> 1. What recurring capability does str_mask() provide that cannot already
> be expressed clearly with existing string primitives?
>
> 2. Do we have evidence from real-world codebases that this pattern occurs
> frequently enough to justify another global function rather than a small
> userland abstraction?
>
> 3. The RFC states that the implementation is "significantly faster". Could
> you include reproducible benchmarks against an equivalent
> substr_replace()/str_repeat() implementation, including short strings
> representative of the examples in the RFC?
>
> For operations on strings this small, C being faster in isolation does not
> necessarily establish that the difference is meaningful enough to justify
> expanding the standard library.
>
> I would also avoid describing this as providing privacy or GDPR
> compliance. Whether exposing part of an identifier is appropriate is
> contextual, and a generic byte-level replacement operation cannot provide
> that guarantee.
>
> I think these questions should be resolved before discussing the
> implementation itself.
>
> Best regards,
> Pratik Bhujel
>
--------
Hi Pratik,
Thanks for the feedback! I've updated the RFC document to reflect the
fail-closed error handling design and edge-case behavior we discussed.
Regarding `grapheme_mask()`, I haven't designed or implemented it yet, but
I will definitely incorporate these principles once I start working on it
in `ext/intl`.
Also, to ensure this on it in `ext/intl`.
Also, to ensure this to include real-world usage analysis/benchmarks (e.g.
log masking, sensitive data display in popular frameworks) in the proposal?
I'd love to hear your thoughts on this or any specific cases you have in
mind.
Best regards,
Sepehr
