Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102764
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
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>
 <CAFMT4Np-sQ4MtGyN_M1t=pEY05gv7QDrUgPO2j3LZKe5G3tCSw@mail.gmail.com>
In-Reply-To: <CAFMT4Np-sQ4MtGyN_M1t=pEY05gv7QDrUgPO2j3LZKe5G3tCSw@mail.gmail.com>
Date: Wed, 11 Jul 2018 10:20:40 -0600
Message-ID: <CAFMT4Nqt1ZymBdL3YbV69yj-eOPU-RoWC5EONsOhYLjnm-Fpfw@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>
Cc: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>, 
	enno.woortmann@web.de, mail@pmmaga.net, me@jhdxr.com, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()
From: levim@php.net (Levi Morrison)

On Wed, Jul 11, 2018 at 10:16 AM Levi Morrison <levim@php.net> wrote:
>
> On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker <cmbecker69@gmx.de> w=
rote:
> >
> > On 11.07.2018 at 17:19, Bj=C3=B6rn Larsson wrote:
> >
> > > Den 2018-07-11 kl. 02:41, skrev Levi Morrison:
> > >
> > >> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalh=C3=A3es <mail@pmmaga.n=
et> 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 mist=
ake.
> > >>>>
> > >>> 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 =3D> null]).
> > >>>
> > >>> Regards,
> > >>> Pedro
> > >> To safely use it a call to empty or count or something needs to happ=
en:
> > >>
> > >>      if (!empty($array)) {
> > >>          $value =3D 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] =3D array_first($array)) {
> > >>          // do something with $value
> > >>      }
> > >>
> > >> People who argue against the tuple because they don't like the desig=
n
> > >> 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>.
> >
> > --
> > Christoph M. Becker
>
> This was not discussed, it was discarded. Enormous difference.

As an example, it was claimed:

> If I use a function I expect it to give me a return value which I can
> use without any further post processing $wantedValue =3D
> fancyFunction($someInput);

But this isn't true even for the array_value_* functions. There must
be pre or post processing because of error conditions. This was
pointed out by myself and others, but it was still ignored.

This is what I mean by discarded, not discussed.