Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121394 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 57251 invoked from network); 18 Oct 2023 13:38:31 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Oct 2023 13:38:31 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D9FB618050B for ; Wed, 18 Oct 2023 06:38:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 18 Oct 2023 06:38:30 -0700 (PDT) Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-49ab3f5863fso409753e0c.1 for ; Wed, 18 Oct 2023 06:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697636309; x=1698241109; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CFuGyRPuv4OU05IRAodTakJlKyBV5w0MbyNX/txMMAo=; b=BeSuDCuc5duCSJfaPEHsLI1M04sF9286NLUs80QX6Vo2tHGREwusmpTqVDOZ2qlpbv QADccN8b06IzndodRdKt47c7PDVUtJ/G1mhnFWuu7x0pHsxw4ow7psKHcz5/rR/8YsPu PmRoZ0uyGMkM2qoV1U53uovEaZZQGGDX3EqxkONJ676Q6lM5Re6Ox586p4b7tUllKTj5 L0+m/dAzWvQTmfvM1whdEJ+Dvq822/Ykd6UAEw7Ccx1MvIygN22rn3Wj9CWf7c6de2mY NIf0F9J5S6/Th12Hsl1nw+DJo+M0sZY7SWmk7FNm09B4NOG/luCmj9Xfmlxm8w1ag4RG MI5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697636309; x=1698241109; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CFuGyRPuv4OU05IRAodTakJlKyBV5w0MbyNX/txMMAo=; b=d3WNHPYSqVrFaWMu1mQZYzxy0CUlo9ePCui3CHOFAGM1l0gttnOgYP/zCHs/eLYFKo BqLVXIMpqBlwaPFmUPOBdMxoCOJP2qqAzwkcA3HEZA9aAdlimE/2hXJXuqVrAhTiIcc8 1GYCkabXMcIQuY1zQ1+fsTphLQi6x+LQDQYfKd5xlO0MB2sE6uywcFkBNqc+c1bqmJg/ fXssIHGSBGgK9C0hULx1mDOys4FI+AxiptF4e2cE2nIH1jAG2q187Pyfeq8fLDD+sOV4 aYlZ/kAzY+svLwZVB8XDWJq242qCm7XRrijhWD9bZI3yAAXo82UxALo1OXrKGjbY5WmW ThuA== X-Gm-Message-State: AOJu0Yxu4uD4dfPPLvVG+aLZmJfQCPIAF7F4eIlLETRvFtGlFFtrvobL kfAUI9gD5JFpDvnykdvHaQH+H67Gt6MaZiUl77k= X-Google-Smtp-Source: AGHT+IHYv/FYTGdZjlhOtrHkSi95lSZuijjFI3oDCZ4UAaHSld5QQ3AoR7WSTXKIa/QrXyy26lbDK9WNoPbK041Nsmw= X-Received: by 2002:a05:6102:21c7:b0:457:cccf:75f0 with SMTP id r7-20020a05610221c700b00457cccf75f0mr3889850vsg.2.1697636309422; Wed, 18 Oct 2023 06:38:29 -0700 (PDT) MIME-Version: 1.0 References: <173ca550-71a0-4bd4-96f2-b64b6155115a@app.fastmail.com> In-Reply-To: Date: Wed, 18 Oct 2023 10:37:53 -0300 Message-ID: To: Brandon Jackson Cc: Levi Morrison via internals Content-Type: multipart/alternative; boundary="0000000000002e5b480607fdc179" Subject: Re: [PHP-DEV] Two new functions array_first() and array_last() From: deleugyn@gmail.com (Deleu) --0000000000002e5b480607fdc179 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 18, 2023 at 10:11=E2=80=AFAM Brandon Jackson wrote: > > I get your desire to keep things simple, but IMO returning a value > that does not conflict with possibly valid values or somehow indicates > the value was not present is important, and should come before > simplicity. Which likely means involving the key somehow. > The only portion in your email I disagree with is this ending. I believe there are enough use-cases where if the first value is "valid null" or "default null" it won't matter. The developer will treat them both the same. Perhaps you disagree with this and want to avoid ambiguity at all costs. My proposal to avoid ambiguity would be throwing an exception instead of involving the key because involving the key can be a composition between `array_first()`* and `array_key_first()`. Although I would prefer the function to throw, I think it will have the same effect as this key discussion: complicate something that can be simple. If the developer needs to distinguish between "default null" and "value null", they are able to do so by running `empty()` on the array prior to asking for `array_first()`. It's actually better than a try/catch, to be honest. Ultimately, there's 2 parallel discussion that somewhat intertwine themselves: Fibers ("async" code) and ambiguity ("value null" vs "default null") and while there are options that may cater for both of them, there are also options that cater only for each of them individually. Trying to over-pollute a function as simple as `array_first()` to cater for these edge cases is where I think the problem is because userland will always be able to tackle these issues by wrapping the basic functionality provided by core. * If naming is an issue to you, I'd also be fine with `array_value_first()`. --=20 Marco Deleu --0000000000002e5b480607fdc179--