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