Den 2018-07-11 kl. 17:27, skrev Christoph M. Becker:
On 11.07.2018 at 17:19, Björn Larsson wrote:

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

On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <> wrote:

On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <> wrote:

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
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
function that still accepts non arrays just to return null with a
doesn't make sense at this point.

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

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
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?
This already has been discussed weeks ago, see

Aha, tnx.

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:

Reply via email to