________________________________ From: Kamil Tekiela <tekiela...@gmail.com> Sent: Wednesday, February 1, 2023 11:55 AM To: Sergii Shymko <ser...@shymko.net>; PHP internals <internals@lists.php.net> Subject: Re: [PHP-DEV] RFC proposal: function array_filter_list() to avoid subtle bugs/workarounds
Hi Sergii, First of all, let me say that I am glad more people are willing to give back to the PHP language. I'm happy you decided to join the ML. However, the change you are proposing is unlikely to be well-received. PHP already has too many functions. It is known as a kitchen sink[1]. I don't think we need list-variants of the array functions. As you noted yourself, it can be simply implemented with array_values(). If we do this one then next someone will say what about array_diff() with a list? Most of the functionality can be implemented in userland and it's usually the preferred way. If we are going to add a new function to PHP, it must have a very good reason to be implemented in C. array_is_list() had a very good explanation: performance. Ideally, we would have a separate type for List, but... it can easily be implemented in userland so we are back to square one. While PHP's arrays are something of a Frankenstein's monster, they work well as an internal implementation detail of other data structures. Adding more array_* functions is something that many of us would want to avoid. Regards, Kamil [1]: https://web.archive.org/web/20181107125816/http://www.mcguirehimself.com/?p=117 Hi Kamil, Thanks for your thoughtful feedback! The argument about list-flavored versions of other array_* functions is a very strong argument. I'm glad you're bringing it up, because that aspect worries me a lot as well. Array functions producing a subset of a list are all logically expected to return a list. I think, this assumption is only applicable to array_filter(), array_[u]diff(), and array_[u]intersect(). These are basically all array functions that already have an array_*_assoc() version. Since we already distinguish assoc arrays, doing the same for lists seems pretty reasonable. You're right, we can totally anticipate people requesting array_diff_list() and array_intersect_list(). I've got mixed feelings about that, also not a fan of multiplying the number of array functions. In practice, I've only encountered the need for array_filter_list(), but not others. Filtering is different from other functions as it operates on a single array instead of multiple arrays. Maybe it's a sufficient reason to treat it separately from other array functions, maybe not.
