Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102763 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38750 invoked from network); 11 Jul 2018 16:16:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jul 2018 16:16:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=morrison.levi@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=levim@php.net; sender-id=unknown Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender) X-PHP-List-Original-Sender: morrison.levi@gmail.com X-Host-Fingerprint: 209.85.215.47 mail-lf0-f47.google.com Received: from [209.85.215.47] ([209.85.215.47:40242] helo=mail-lf0-f47.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 65/49-15421-F5D264B5 for ; Wed, 11 Jul 2018 12:16:32 -0400 Received: by mail-lf0-f47.google.com with SMTP id y200-v6so21751482lfd.7 for ; Wed, 11 Jul 2018 09:16:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7kiHbIdmuCl1KNG7bKMLsAIjXKBl5ofdFnSJm8fF6ao=; b=gkvS6JCA419DmUd95+yQky35wxpF7/MDozdgnsTw5PLVji8atKMHoK3+H9rxiZqHTE 6eay38lAk5jnEvsDr2bW7JFWdodXzO9NecQ/ciz6llX5wIm+WsEdARtEmnQR4GyuZAXJ GT0ZRInPg+nhLIp2tiQuLWJ8ZhnUyNDzy8+czQ2VbfGujJP76lgf1jkeRL8pzEyhUrhh iOh6TsZTKb/asX+Ac4UlRnxwAIFzRxaY7b3HHhge+WFHTDFaW08WLSpoRaqGIEUyOXBF 8Z+sc6rFQWIPD6KDE4kMFSm4h59dVwcrPK3vh1HEo5yOrtzruxtgUuBp/hUcNrGPYmwp 0dWQ== X-Gm-Message-State: APt69E1hKyNqZrcsLtXNLdlHrw8J6GcDGJuu3uRx8LSM6s92mBLOan6J gp9HInotvKno8aMzwupwGXL+Lgax0IItDetxUhw= X-Google-Smtp-Source: AAOMgpcyiqxlvjibn8cH32VXgrBiYhpI4iARai8iPzWVLh2P4uQJrWTRNmBZlgUyG7dw/WduW4AfIXgv1NQZG9MZkXc= X-Received: by 2002:a19:5d54:: with SMTP id p20-v6mr6236364lfj.143.1531325788510; Wed, 11 Jul 2018 09:16:28 -0700 (PDT) MIME-Version: 1.0 References: <13b4eb91-6566-3724-d45d-aa63254e1f58@telia.com> In-Reply-To: Date: Wed, 11 Jul 2018 10:16:16 -0600 Message-ID: To: Christoph Becker Cc: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= , enno.woortmann@web.de, mail@pmmaga.net, me@jhdxr.com, internals 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 9:27 AM Christoph M. Becker wro= te: > > 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 wrote: > >> > >>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei 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 mistak= e. > >>>> > >>> 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 happen= : > >> > >> 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 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 > . > > -- > Christoph M. Becker This was not discussed, it was discarded. Enormous difference.