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 <[email protected]> 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 > >
