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

On Tue, Jul 10, 2018 at 6:41 PM Levi Morrison <levim@php.net> wrote: > > 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.