Den 2018-07-11 kl. 02:41, skrev Levi Morrison:
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
