Re: [RFC] array_partition()

From: Date: Tue, 27 Oct 2026 10:35:36 +0000
Subject: Re: [RFC] array_partition()
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-132943@lists.php.net to get a copy of this message
Hi Tim, Thank you for the careful read, and for the kind words. I've updated the RFC: - Fixed the "[[], []]" rendering in "Semantics in detail". - Added is_string(?) to the arity example. I verified that it works with the implementation. - Linked the declined Destructuring Coalesce RFC from the missing-buckets argument and from "Related RFCs". - Rewrote the first paragraph of "Backward Incompatible Changes": with or without a function_exists() guard, an existing userland array_partition() needs to be checked against the native semantics. - Replaced the stub in the proposal with a userland implementation using foreach. While checking it against the native function, I found one difference: the native function keeps by-reference elements as references, like array_filter(), and the foreach version does not. The RFC mentions it right below the code. Best regards, Ayoub On Mon, Oct 26, 2026 at 10:37 PM Tim Düsterhus <tim@bastelstu.be> wrote: > 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 (#132943) next »