در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۱۷ 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
