[RFC] array_partition() View as Markdown

Hi mickmackusa,

Instead of potentially creating array_partition() and eventually
array_group(), I feel any benefits of array_partition() should be baked
into an array_group() function for greater utility in a unified function.

Thanks for thinking it through. Seeded keys would indeed solve the
missing-bucket problem, and with string labels the result reads well:

['adults' => $adults, 'minors' => $minors] = array_group(
    $users,
    fn($u) => $u->age >= 18 ? 'adults' : 'minors',
    ['adults', 'minors'],
);

I still think the two-way split deserves its own function, for three
reasons:

1. Destructuring is by key, not by order. With a boolean callback, the
   keys become 1 and 0 whatever order they are seeded in, so
   [$adults, $minors] = array_group($users, $predicate, [true, false])
   puts the minors in $adults. You have to switch to labels, as above.

2. With labels, the callback, the seed list and the destructuring keys
   have to agree. A typo ('adult' vs 'adults') silently creates a third
   group and leaves one variable empty. array_partition() only needs a
   predicate, and its result shape is fixed.

3. PHP already pairs general functions with simpler, specialised ones
   for common cases: array_filter() with array_find() and array_any().
   A two-way split is common enough to warrant the same treatment.
   It doesn't rule out a future array_group(), which raises its own
   design questions (return shape, unknown keys, key preservation).

I'll add the seeded-keys alternative to the RFC's "Why not a general
grouping function?" section.

Thanks,
Ayoub

I wouldn't be disappointed to see array_partition() added to the language, but the longer I think about it, a well-designed array_group() function could provide the equivalent behavior as well as afford other than just 2 static groups.

It seems like the only relevant difference is the fact that array_partition() always returns an indexed array of two arrays without needing to push 2 empty arrays for padding. Theoretically, array_group() might not return any subarrays when there are no qualifying items to retain. Does array_group() need an optional 3rd parameter which declares an empty array for each nominated grouping key which can be nominated in a particular order? Food for thought.

Instead of potentially creating array_partition() and eventually array_group(), I feel any benefits of array_partition() should be baked into an array_group() function for greater utility in a unified function.

mickmackusa

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

Hi

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