Re: [PHP-DEV] [RFC] [Discussion] array_match

Hi everyone,

Apologies, there was a typo in the link I just sent.
Here is the correct link to the updated RFC:
https://wiki.php.net/rfc/array_str_contains

Thanks,
Sepehr


در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۱۴:۵۸ سپهر محمودی <[email protected]> نوشت:

> Hi everyone,
>
> Thank you all for the valuable feedback, especially regarding the
> complexities of case-insensitive searches and locale dependencies.
>
> Based on the discussions, I have updated the RFC and simplified the design
> to avoid those issues. Here are the major changes:
>
> 1. The function is now strictly case-sensitive (byte-for-byte matching).
> This ensures native support for UTF-8, non-Latin characters, and emojis
> without the need for complex decoding.
> 2. The $ignore_case parameter has been removed. The signature is now
> simply: array_str_contain(array $haystack, string $needle): array
> 3. The implementation target is moved to ext/standard, completely removing
> the ICU dependency and improving performance.
> 4. The target version is set to PHP 8.6.
>
> You can review the updated RFC here:
> https://wiki.php.net/rfc/array_str_contants
>
> I believe this simplified version covers the primary use cases while
> eliminating the performance and localization bottlenecks we discussed.
>
> I would appreciate any further thoughts on this updated design.
>
> Best regards,
> Sepehr
>
>
> در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۵۰ سپهر محمودی <[email protected]>
> نوشت:
>
>>
>>
>> در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۱۷ mickmackusa <[email protected]>
>> نوشت:
>>
>>> I just want to add a few points to the discussion.
>>>
>>> With an increasing number of software developers offloading code writing
>>> to AI, there's probably a decreasing weight to which "ergonomics" can be
>>> argued. Don't get me wrong, I love concise and elegant code, but not for
>>> _code golfing_ reasons and there are diminishing returns in such adventures.
>>>
>>> As for performance arguments, we need to see real benchmarks versus
>>> related processes returning the same result to understand the amount of
>>> performance gains. We may also need to understand if there are thresholds
>>> where the performance differences are more/less noticeable.
>>>
>>> This proposal is coupling one iterating function with one string
>>> function. Think about the precedent adopting this proposal would set. Would
>>> the language slip into bloating its array function family with tens of
>>> other combinations _for performance/ergonomic reasons_?
>>>
>>> I am not in favor of the array_match() or array_str_contains()
>>> proposals, but an alternative not surfaced in this thread is the idea of
>>> polymorphism with the already existent str_contains() function. In other
>>> words, make it behave like str_replace() whether a haystack parameter is a
>>> string or an array of strings. I don't know if the language is trying to
>>> avoid such a convention, but I know I've personally wished that
>>> `preg_quote()` could directly receive an array of strings before imploding
>>> its result with pipes (and I've seen countless php-regex posts on Stack
>>> Overflow of array_map() making preg_quote() calls before imploding).
>>>
>>> While it is completely natural to muse language modifications based on
>>> our own encounters with development, before devoting time to a proposal,
>>> sense check that the change would significantly improve the language and
>>> benefit a significant number of developers and codebases.  Maybe take time
>>> to silently draft 3 to 5 distinctly different proposals, then critically
>>> compare and rank them from most to least compelling for general developers,
>>> then deliver your best proposal. Such an exercise will help you to
>>> self-evaluate which proposal(s) are ready to share with the internals
>>> mailing list, which ones need more consideration, and which ones might
>>> never become compelling proposals.
>>>
>>> Sincerely,
>>> mickmackusa
>>>
>>
>> -----------
>>
>> Hi everyone,
>>
>> Thank you all for the valuable feedback on the `array_str_contain`
>> proposal so far.
>>
>> Based on the recent technical discussions, especially regarding Unicode
>> handling and performance (thanks Yuya for the insights), I am focusing the
>> design on a UTF-8 by default approach. This will ensure full and efficient
>> support for non-Latin characters and emojis, which aligns perfectly with
>> modern web standards.
>>
>> I am currently refining the implementation and will update the RFC
>> details accordingly. In the meantime, if anyone has specific edge cases
>> regarding this UTF-8 approach that I should keep in mind during testing, I
>> would be happy to hear them.
>>
>> Thanks again for your time and guidance.
>>
>> Best regards,
>> Sepehr
>>
>>