Re: [RFC] array_partition()

From: Date: Mon, 26 Oct 2026 22:37:24 +0000
Subject: Re: [RFC] array_partition()
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-132938@lists.php.net to get a copy of this message
Hi On 10/25/26 14:38, Ayoub EZZINI wrote:
I'd like to start the discussion on a new RFC: https://wiki.php.net/rfc/array_partition
Thank you for your RFC. Incidentally a co-worker has hand-written an array_partition() just last week (using two array_filter() calls), so clearly there is some appetite for it. I've just read the RFC and noticed a small rendering issue in the “Semantics in detail” section. For the “An empty input” bullet point it seems you didn't properly escape the code and it was interpreted as Wiki markup. For the arity example, you could add that is_string(?) with PFA’s ? placeholder should work, since it behaves like a userland function. For the “why not a general grouping function” section, I would like to point towards the declined https://wiki.php.net/rfc/destructuring_coalesce RFC, which is somewhat related to the “The buckets are only created when at least one element falls into them” argument. For the “Backward incompatible changes” section, I'd like to note that even for users defining array_partition with a function_exists() check nothing guarantees that their custom implementation behaves the same, so they would need to adjust their code either way. This is acknowledged in the second paragraph, but the initial paragraph is somewhat misleading. In any case, adding new symbols is not considered a breaking change as per policy and the arguments for the proposed name are strong, so this is not a hard blocker (but must be mentioned nevertheless, as you did). Perhaps it would also make sense to extend the stub in the proposal section to a full “userland polyfill” (using the foreach loop), similar to what the array_find() RFC did. This can help make the behavior clear in a way that pure prose can't. Other than these small polishing nits, I don't have anything to remark about the RFC other than: It's a well-written, well-researched and well-argued RFC and I'm in favor of the proposal. Best regards Tim Düsterhus

« previous php.internals (#132938) next »