This will need an RFC :) See https://wiki.php.net/rfc/howto for more info.

Return the array's first key (and optionally, value), could you provide some examples of this maybe? I'm not sure what this method does, simply a getter or also a setter if the second argument is provided? Note that this is quite inconsistent with other php functions.

@iltar A more full description is in the RFC for this PR, with examples: https://wiki.php.net/rfc/array_key_first_last_index

👍 in general but I think this would be alot less confusing without the optional values for array_key_first and array_key_last

I don't see why this is necessary, considering it can be done with 4 lines of polyfill (not counting declarations): https://gist.github.com/shadowhand/844f5005d51c7f5c75c2

reset() modifies the array, which in your polyfill, forces a copy to be made. For large arrays, this can be slow and consume memory. A significantly more performant (in PHP 7 only) polyfill for array_key_first would be:

function array_key_first(array $arr)
{
     foreach($arr as $k => $v) {
        return $k
    }

    return null;
}

But that is honestly still a pretty kludgy solution, and does not actually help with making array_key_last() performant.

The reason the RFC exists is because there is no way to do this in userspace without writing code that is fast, and does not look weird, and does not modify the source array.

Maybe it would be more helpfull to add functions to get & set the position the internal array pointer is pointing to? those could be more usefull for other scenarios and we dont need to add 2 methods for a certain "edge-case"...?

@staabm The purpose of these new functions isn't about changing the internal pointer, there are already functions to change the pointer e.g. next(), but no functions like these.

@jbafford 👍 from me. I can see a lot of usage of these new functions.

The purpose of these new functions isn't about changing the internal pointer, there are already functions to change the pointer e.g. next(), but no functions like these.

there isnt. you can only move the pointer forwards/backwards but nothing like "tell me where the pointer atm is" or a "set the internal pointer to position x".

@staabm There is...

tell me where the pointer atm is

key($array) [http://php.net/manual/en/function.key.php]

set the internal pointer to position x

You can use @shadowhand's polyfill code: [https://gist.github.com/shadowhand/844f5005d51c7f5c75c2]

But you are missing the point, there are no functions that don't touch the pointer currently. In a lot of cases, you don't want the pointer to change, this is where these new functions will get the job done.

@jerrygrey as commented in https://gist.github.com/shadowhand/844f5005d51c7f5c75c2 with the current functions you need to copy the array to get the required functionality, which wouldnt be required in case we could read/write the position of the internal pointer.

@staabm I just had a look and all the functions that changes the internal array pointer has a copy element in them, so it would be unavoidable to have a function that changes the pointer without a copy.

The concept of the internal array pointer is an implementation detail, which I don't think should be further leaked into userspace. In any case, that's completely distinct from the problem this RFC is trying to solve.

Seems like array_slice should already have (or could be improved to have) the performance characteristics you want, and allows preserving key. (userland implementation)

I'm glad to see that this RFC is still alive with recent activity ... please push it forward ;)

Just a quick note:

This RFC requires a super majority: It is the consensus of core maintainers that "language change" means anything that we have to continue to maintain after it is merged.

Please update the RFC accordingly.

What does it mean that is under discussion for more than 3 months, does it mean this idea is dead?

@jens1o It's only dead in the sense I just haven't had the time or inclination to deal with this for the last year. I've got a little bit of free time, though, so I'll see what I can do about pushing it along. The RFC basically needs a complete rewrite based on the feedback from when this was initially proposed last year.

@krakjoe Can you point me to a thread indicating the reasoning for why this is a "language change" and a supermajority is required? All this does is add a few functions to the function list. Larger changes have required less support than that.

@jbafford Do you have plans to update this RFC? Or someone can surpass this PR?

@carusogabriel This is still on my to-do list, but frankly, I've been busy, and from past experience, not highly inclined to want to spend the necessary mental effort wrangling php-internals.

Realistically speaking, I'm not going to be able to devote any time to this RFC until September or October. That may not be soon enough for the 7.3 merge window, if 7.3 proceeds as 7.0/7.1/7.2. If someone would like to shepherd this RFC into 7.3 before then and thinks they can get a yes vote, then feel free to contact me and I can discuss my recollection of the previous round of discussion and what next steps should be before bringing it up for discussion again. Otherwise, I've set a reminder, and will take a look at it again when I'm back and try and push it through at that time.

@jbafford I've made a different implementation approach with a smaller functional scope covering the basic requirements by adding the functions array_key_first(array $a) and array_key_last(array $a)

wol-soft@ec2332b

I'd like to propose to use the smaller scope, if possible for 7.3.

Is it ok that array_key_first([ null => 1, 'a' => 'b', /* … */ ]) returns null as well as array_key_first([]) does?

Comment on behalf of cmb at php.net:

Since https://wiki.php.net/rfc/array_key_first_last has been accepted and implemented, I'm closing this PR. If you're still interested in adding array_key_index(), I suggest to write a respective RFC.