Hi internals
I'm opening the discussion for the RFC "array_first() and array_last()".
https://wiki.php.net/rfc/array_first_last
Kind regards
Niels
Le 5 avr. 2025 à 17:51, Niels Dossche dossche.niels@gmail.com a écrit :
Hi internals
I'm opening the discussion for the RFC "array_first() and array_last()".
https://wiki.php.net/rfc/array_first_lastKind regards
Niels
Hi Niels,
It is reasonable. I have a userland implementation of that in my codebase since long ago.
You missed the following point when discussing the behaviour for empty array:
- Consistent with
array_shift()andarray_pop(), which are also about retrieving the first, respectively the last element of an array.
—Claude
Hi Niels,
It is reasonable. I have a userland implementation of that in my codebase since long ago.
You missed the following point when discussing the behaviour for empty array:
- Consistent with
array_shift()andarray_pop(), which are also about retrieving the first, respectively the last element of an array.
Hi Claude
Good point, I'll add that as well, thanks.
There are probably even more arguments that can be made :)
—Claude
Niels
Hi internals
I'm opening the discussion for the RFC "array_first() and
array_last()".
https://wiki.php.net/rfc/array_first_lastKind regards
Niels
Hi,
Do you think it would be hard or wrong to add array_nth? I've had more
trouble with that as the in-place implementation is usually pretty
unreadable, e.g.
array_slice(array_values($array), $offset, 1)[0] ?? null
I understand this need is less common, especially compared to
array_first. But I also suspect that an in-engine implementation might
have more performance gains compared to an userland one.
BR,
Juris
I also suspect that an in-engine implementation might have more
performance gains compared to an userland one.
That applies to literally anything, obviously; one less layer of
abstraction is always more efficient. That's therefore not a reason to
add something to the engine. I suggest first proving there is a
legitimate need.
Cheers,
Bilge
... [snip] I suggest first proving there is a
legitimate need.
I did a quick GitHub search for a common pattern of accessing an array
value by using the array_key_first and array_key_last functions:
$value = $arr[array_key_first($results)];
-
[array_key_first(: over 3,700 results[^1] -
[array_key_last(: over 4,300 results[^2]
All of these hits can benefit from the proposed array_first and array_last.
... [snip] I suggest first proving there is a
legitimate need.I did a quick GitHub search for a common pattern of accessing an array
value by using thearray_key_firstandarray_key_lastfunctions:$value = $arr[array_key_first($results)];
[array_key_first(: over 3,700 results[^1][array_key_last(: over 4,300 results[^2]All of these hits can benefit from the proposed
array_firstandarray_last.
Just registering that I am all for this RFC and look forward to using it.
--Larry Garfield
... [snip] I suggest first proving there is a
legitimate need.
I did a quick GitHub search for a common pattern of accessing an array
value by using thearray_key_firstandarray_key_lastfunctions:$value = $arr[array_key_first($results)];
[array_key_first(: over 3,700 results[^1][array_key_last(: over 4,300 results[^2]All of these hits can benefit from the proposed
array_firstandarray_last.
To be clear, I wasn't disputing first/last, but nth, but thanks for the
insights!
Cheers,
Bilge
Do you think it would be hard or wrong to add
array_nth? I've had more trouble with that as the in-place implementation is usually pretty unreadable, e.g.array_slice(array_values($array), $offset, 1)[0] ?? null
I understand this need is less common, especially compared to
array_first. But I also suspect that an in-engine implementation might have more performance gains compared to an userland one.
This is not hard to add. For packed arrays this can be done in O(1) time, for non-packed arrays in O(n) worst case.
If added, it's best to add the pair array_nth() & array_nth_key() together IMO.
However, it's not something I ever really needed nor something that I have seen a demand for.
I think this could be left for the future for follow-up work.
Kind regards
Niels