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 > >
