Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102761
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain telia.com designates 81.236.60.155 as permitted sender)
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Levi Morrison <levim@php.net>, "Woortmann, Enno" <enno.woortmann@web.de>,
 =?UTF-8?Q?Pedro_Magalh=c3=a3es?= <mail@pmmaga.net>,
 CHU Zhaowei <me@jhdxr.com>, PHP internals <internals@lists.php.net>
References: <e8fdd7ca-135a-2a7f-79cd-e45486f4ba8b@web.de>
 <tencent_3910FA2861CB2DDC6DBA9FF9@qq.com>
 <CAJd4=Ybos2TpD5gkBZu3H-ttamojZkDsrNXz8eLyfNgU0bD2Kw@mail.gmail.com>
 <CAFMT4No0iPMOS-BF4QALGNM9HQ7ynEAZr=Og-XH+T0OJxueBQg@mail.gmail.com>
 <13b4eb91-6566-3724-d45d-aa63254e1f58@telia.com>
 <a02bcf08-160a-59d1-a3bc-3ba7460c78bc@gmx.de>
Message-ID: <a487e311-282f-1ad1-d46d-f1d0ccb5bfde@telia.com>
Date: Wed, 11 Jul 2018 17:53:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <a02bcf08-160a-59d1-a3bc-3ba7460c78bc@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Subject: Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(),
 array_value_first(),array_value_last()
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2018-07-11 kl. 17:27, skrev Christoph M. Becker:
> On 11.07.2018 at 17:19, Björn Larsson wrote:
>
>> 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?
> This already has been discussed weeks ago, see
> <https://externals.io/message/102245#102317>.
>
Aha, tnx.