On Tue, Jul 10, 2018 at 6:41 PM Levi Morrison <le...@php.net> wrote:
>
> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <m...@pmmaga.net> wrote:
> >
> > On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <m...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
