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
