[VOTE] array_key_first(), array_key_last(), array_value_first(), array_value_last()

I don't think we have an agreement on dealing with non-existing value, and
the way this RFC proposed, just returning null without any notice/warning,
is wrong IMO. I know we already do this in other array_* functions, but we
cannot keep making mistakes just because we already made same mistake.

I voted no for the same reason. I'd even say that introducing a new array_
function that still accepts non arrays just to return null with a warning
doesn't make sense at this point.

With that said, I'd gladly vote yes if there would be a way to distinguish
array_value_first([]) from array_value_first([0 => null]).

Regards,
Pedro

To safely use it a call to empty or count or something needs to happen:

if (!empty($array)) {
    $value = array_value_first($array);
    // do something with $value
}

This is okay, but not great. Compare that to the design that returns a
tuple though:

if ([$_, $value] = array_first($array)) {
    // do something with $value
}

People who argue against the tuple because they don't like the design
need to consider the bigger picture. The tuple way is less code,
serves more use cases with fewer functions, and I even [implemented
it][1]. If the array destructuring behavior seems unclear we can
simply put an example in the manual pages for these functions --
problem solved.

This is not how RFC feedback should be handled. I hope more people
vote no so we can reject this do it properly.

Le mardi 10 juillet 2018, 18:41:17 CEST Levi Morrison a écrit :

People who argue against the tuple because they don't like the design
need to consider the bigger picture.

My guess is people arguing for the tuple do not understand the usecase :-)

Each time I felt the need for array_first_value was because I was using it on a function return to do something with it.

Like:
if (array_first_value(some_function()) > 3) {
// do something
}

Either I know that the array is not empty, or I do not care because NULL will be ignored correctly.
In the second case, with a tuple I’m stuck because if I do:

if (array_first(some_function())[1] > 3) {
// do something
}

If array_first returns NULL this will trigger a PHP error. So I have to add more code to handle this special case while I do not need any with array_first_value.

Côme

Den 2018-07-11 kl. 02:41, skrev Levi Morrison:

I don't think we have an agreement on dealing with non-existing value, and
the way this RFC proposed, just returning null without any notice/warning,
is wrong IMO. I know we already do this in other array_* functions, but we
cannot keep making mistakes just because we already made same mistake.

I voted no for the same reason. I'd even say that introducing a new array_
function that still accepts non arrays just to return null with a warning
doesn't make sense at this point.

With that said, I'd gladly vote yes if there would be a way to distinguish
array_value_first([]) from array_value_first([0 => null]).

Regards,
Pedro
To safely use it a call to empty or count or something needs to happen:

 if (!empty($array)) {
     $value = array_value_first($array);
     // do something with $value
 }

This is okay, but not great. Compare that to the design that returns a
tuple though:

 if ([$_, $value] = array_first($array)) {
     // do something with $value
 }

People who argue against the tuple because they don't like the design
need to consider the bigger picture. The tuple way is less code,
serves more use cases with fewer functions, and I even [implemented
it][1]. If the array destructuring behavior seems unclear we can
simply put an example in the manual pages for these functions --
problem solved.

This is not how RFC feedback should be handled. I hope more people
vote no so we can reject this do it properly.

I do like this approach with two functions array_first & array_last
returning
a tuple. However, voting is  underway and it looks like it will pass.

I wonder what the RFC author (Enno W) thinks about that approach?

r//Björn Larsson

This is not how RFC feedback should be handled. I hope more people
vote no so we can reject this do it properly.

I agree with the spirit of this RFC but I also agree with Levi. It feels
like this particular implementation is being rushed through without
properly addressing some of the outstanding issues and alternate
implementation ideas that have been raised. The only revisions to the RFC
were the inclusion of the two value-related functions. IMHO, any RFC going
to vote despite known "opposition" or requested changes should at least
contain a summary of those points and counter-points, but if feels like
those are being ignored here.

So while I do understand the value of such a feature, I'd much rather delay
its implementation than to rush it along with potential issues and no
strong consensus.

Respectfully,

Colin O'Dell
[email protected]
https://www.colinodell.com

Le jeudi 12 juillet 2018, 01:04:36 CEST Andrea Faulds a écrit :

Hmm. Returning null with no warning makes perfect sense for keys, since
null is not a valid key so there's no ambiguity, but for values it seems
problematic. On that ground I've decided to change my vote to No for the
value functions, but keep the vote for Yes for the key functions.
Someone who wants such behaviour could always do
($array[array_key_last($array)] ?? null), I guess.

Ditto!

You cannot do that easily if the array is returned by a function.
function()[array_key_last(function())] would call the function twice.

You can easily store the function's return value in a variable, though.

--
Christoph M. Becker

Not sure what timezone you are in; current votes are:

Add array_key_first() and array_key_last()?

• Yes (19)
• No (13)

Add array_value_first() and array_value_last()?

• Yes (16)
• No (17)

The first vote will pass with 59.375%. The second fails at ~48.48%.

A function like array_offset would be convenient as there is no way to
access the value of an array entry by its index currently. The workaround
is using array_slice, with all the downsides already pointed out.

2018-07-13 20:04 GMT-03:00 Levi Morrison [email protected]:

On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno [email protected]
wrote:

Hi,

as the discussion got no new contributions I'd like to start the
voting
for the RFC fo add new functions for the handling of outer array
elements.

https://wiki.php.net/rfc/array_key_first_last

To have a better separation I split up the vote for the functions.
The
first vote covers the functions to handle keys: array_key_first() and
array_key_last(). The second vote covers the corresponding functions
to
handle the values: array_value_first() and array_value_last().

As this RFC adds functions but doesn't change the language syntax a
50%

• 1 majority is required for both votes. The votes are open until
  2018-07-16.

The discussion for this RFC is located at

https://externals.io/message/102245

Regards,

Enno

--

This entire time I felt like this should be possible in pure PHP.
Surely, somewhere, we have this capability already? I searched quite a
few functions but didn't find anything.

However, the feeling was right. Just moments ago Paul Crovella from
Stack Overflow mentioned to me that array_slice uses the terminology
offset to refer to the order of the entry rather than its key, so I
went looking. As far as I can tell from the array_slice
implementation it will not trigger copies and will be efficient if
using -1 to retrieve the last index. We can provide the parameter
preserve_keys an argument of true to get both the key and the value.
These functions are efficiently implementable in user-land!

Below is a proof-of-concept for the array_offset function [mentioned
by Nicolas Grekas][2] (which by the way, neither the RFC author nor
anyone else responded to this suggestion) that is simply a convenience
wrapper over array_slice:

function array_offset(array $input, int $offset): ?array {
    $slice = array_slice($input, $offset, 1, true);
    return count($slice) ? $slice : null;
}

$assoc = ['one' => 1, 'two' => 2, 'three' => 3];
$packd = range(1, 4);

var_dump(array_offset($assoc, -1));
var_dump(array_offset($packd, -1));

var_dump(array_offset($assoc, 0));
var_dump(array_offset($packd, 0));

Of course, the array_slice function can be used to build all of the
functions described in the RFC, as well.

My new opinion is that no new functions are required and that
improving the array_slice documentation is all that is necessary. It
currently does not show any examples of it working on associated
arrays, which is probably why none of us (many of us experts) realized
this through this discussion. This is especially true as "offset" in
some other situations really means "key", as in
ArrayAccess::offsetGet.

b9963969fd088dca6852483fdb1c6b7e1080764d/ext/standard/array.c#L3477-L3577
[2]: https://externals.io/message/102245#102322

Small correction: Nicolas used the name array_index, not
array_offset.

Unfortunately I was too hasty: array_slice will iterate over the
entire input range:

https://github.com/php/php-src/blob/b9963969fd088dca6852483fdb1c6b

7e1080764d/ext/standard/array.c#L3538-L3552

We could add an case for when array_slice uses -1. I wonder how
common this already is. Does anyone have a tool that easily can search
open source code for usages of functions? I am interested in this
regardless of the outcome of this RFC. The documentation for
array_slice should also be updated independently of this RFC as
well.