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

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

On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <mail@pmmaga.net> wrote:

On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <me@jhdxr.com> 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 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