Two new functions array_first() and array_last()

[dg]

Description

PHP lacks two very basic functions for working with arrays:

• array_first() returning the first element of an array (or null)
• array_last() returning the last element of the array (or null)

While PHP has functions that return the first and last keys (array_key_first() and array_key_last()), it does not have more useful functions for values.

Thus, programmers "abuse" the reset() and end() functions for this purpose. The problem is that:

• these functions are used to move the internal pointer in the array
• which is why they have a name that is inappropriate when used in the sense of "return me the first element"
• have a side effect (i.e. moving the pointer)
• in the absence of an element, they return the obsolete false and not the currently expected null, which can be combined with the ?? operator
• in this they differ from the similar functions array_key_first() and array_key_last()

[damianwadley]

$array[array_key_first($array)]???

Anyway, two such functions were proposed and rejected during the array_key_first/last RFC.

[dg]

Why closed right away?

$array[array_key_first($array)]???

This can only be used with a variable. See array_first($this->getFoo()) versus $this->getFoo()[array_key_first($this->getFoo())].

Anyway, two such functions were proposed and rejected during the array_key_first/last RFC.

Yes, that was in 2018. At that time, functions like str_contains() or str_starts_with() wouldn't have even come into existence, just because there was an obscure way to replace them. I believe we've moved on since then.

[damianwadley]

Why closed right away?

Because I was online when I saw it come in.

This can only be used with a variable.

Oh, using a variable, how dreadful.

Yes, that was in 2018. [...] I believe we've moved on since then.

And you took the appropriate steps to my closing of this issue: going to the mailing list because you wanted to revive the subject.

But 5 years of PHP actually isn't that long, and more often than not, "I know this was decided on a few years ago but I want to bring it back up again" doesn't pan out. Will it work this time? Dunno.

[iluuu1994]

Please stay civil, personal attacks are not tolerated.

These functions seem useful to me. However, languages changes require at least a discussion on the mailing list and when there is disagreement an RFC. Since these functions have been rejected in the past, an RFC is likely necessary. We usually close GitHub issues that require RFCs specifically because the issue itself isn't helpful in advancing to a solution.

[bukka]

Technically we should not be closing issues right away but instead mark such issue with Status: Requires RFC so I'm going to re-open this as the discussion on ML seemed positive. I will also unlock it in a believe that involved people cooled down so please keep this purely technical and civil.

[damianwadley]

I don't like the array_(key_)first/last concepts, for reasons that are irrelevant, but that doesn't matter to me as far as these Issues are concerned. I'll enforce what guidelines and rules PHP wishes to adopt, but there do need to be actual guidelines and rules that can be followed - without, everyone is just going to do what they think is right.

Technically we should not be closing issues right away but instead mark such issue with Status: Requires RFC

My point was that there already was an RFC and the feature was declined. Yet I do acknowledge it happened >5 years ago, and that's a long time in the tech industry, so the question becomes "how long after an idea has been voted on and declined before it can be proposed again"?

Is 6 months the answer? That's only half of a minor version of PHP so it seems kinda short. I'm also considering that the (informal) feature proposal process has been opened up to everyone on GitHub instead of just those who've subscribed to the mailing list, and that document does predate issue reporting being available here, so is a more conservative period of time desirable?

so I'm going to re-open this as the discussion on ML seemed positive

I'm no mortician, but the conversation died a month ago - without an RFC.

That said, I do agree that it makes sense to leave requests open as "Requires RFC" and let them get closed automatically, if that's what eventually happens*, but we should be doing so consistently; I'm thinking of a few requests that have been closed early (and not by me) for reasons such as "it's a well-known idea" and "saying it needs an RFC counts as resolving the issue".

---

* The bot kicks in after ~3.5 months, and that's plenty of time to go through the RFC process.

[bukka]

Think 6 months is fine because it gives some chance to make changes and propose the feature potentially in the same cycle again which I think is a good thing. Anyway it's the time given in the RFC so this should be clear unless changed.

I would personally put that label only on a big features that require some sort of bigger design or something where there is not an agreement like this one. If it's not a huge features and there are no objections, then there is no need to put the label IMHO

We can probably close things that completely don't make any sense and there is no feedback. But I try to not close it immediately as there should be always a bit of time given to OP to respond. Maybe we should just put request for feedback on it and again not close it directly.

I agree it would be good to have some guidelines on this.

[SVGAnimate]

another possible way to achieve this is to use list

list($first => $v) = $array(1, 2, 3);

[..., $last => $v] = $array(1, 2, 3);

this requires an rfc

Or , because Zend does not distinguish between $array[] = 1; (ZEND_AST_DIM) and $null = $array[]; (ZEND_AST_DIM)

$array=$array(1, 2, 3);
$v = $array[];// last value
$keys = array_keys($array);
$k = $keys[];// last key

Or ,

foreach($array as $k=>$v) break;// first
foreach($array as $k=>$v) continue;// last
// if(isset($k))

whatever happens, you will always have to check array_key_exist()

this requires an rfc

issue itself isn't helpful in advancing to a solution.

Please let the problem describe itself. A problem without a solution is an ill-posed problem.

Thus, programmers "abuse" the reset() and end() functions for this purpose. The problem is that:

Wouldn’t training be the solution?

[SVGAnimate]

for me, the problem is that array supports all types as values. It is therefore impossible to distinguish whether a last value exists.

Unless we introduce the undefined keyword/value.

And that would allow me to do:

function foo(?int $a = undefined) {
}
foo();
foo(null);

$first = array_first($array);
if ($first==undefined) {
} else {
}

Post-Edit:
For this to work, undefined must be a keyword. It must represent a value outside of PHP's set of types.
Consequently,

<?php
$a = undefined; // Is invalid
$a = break; // Parse error: syntax error, unexpected token "break"

[MorganLOCode]

$first = array_first($array);
if ($first==undefined) {
} else {
}

Or you could write

if(empty($array)) {
// Instead of declaring a variable $first that would have a meaningless non-value here.
} else {
$first = array_first($array);
}

and avoid breaking the type system with values that don't have types.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.

[TimWolla]

There is now a PR / RFC: #18210