Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112379 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 33869 invoked from network); 2 Dec 2020 18:18:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Dec 2020 18:18:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C8AC41804C3 for ; Wed, 2 Dec 2020 09:46:01 -0800 (PST) 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_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 2 Dec 2020 09:46:00 -0800 (PST) Received: by mail-ej1-f52.google.com with SMTP id lt17so5698776ejb.3 for ; Wed, 02 Dec 2020 09:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3rG3kBp0Lmxe+EgLvaIKCBmTddEmhFuPW2epoOmOxpc=; b=rbyXfvea8mbgFDtW/s1l7dDTf7d2hHFXbSQApMUXdTMX0YCy9zcyy16GG4fjxTJlzq gS13ZiYp2XssJF4j0q14X9NJBXUtWPcRqkrOPyqc2RsLRKF09Uj8K8HicOdJ0vIBLGXF JolngfOkfjXgZDz6cE6A5QmwtKH+Gkz/bzTwSshLIAFF/y4ikPX0cmv4wj8079J3TxHK Qs6Lg2mBeaB1lM792uhtsx4jv7pG4MtA9BV0UbuxW47Bf6Ziw+Cj4NE59HHrfy4vIh04 r3lEdO1p67Cnylf4HUr22MOIr6HkaUFjD4Si5Uz7GVXuLZIqRtGzuH1e5rNh8lRwJ3UF JfEA== 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; bh=3rG3kBp0Lmxe+EgLvaIKCBmTddEmhFuPW2epoOmOxpc=; b=gS6S1zJmm1rH3A+PsniriD7Ls0CQj6WfScAUzX+nPSIGvmuLOZB53ivKDWy14xdLl9 O5+gA0tk5h6I5+DRVHFFL78pwcYwRnXBKIetCDFJklVGyp4KxB3FPffdEVSr2CtxwrJ2 mDAKfAK/l7pKuPP/0loBST2qzz9d7JVYT143yZf5O/8R9CnDP8hXyV4cSe6Aj7HF0uHE 7pQvYvNPuGxszviG4VofZ4DJOq2oezilmXWAyGl+r2sBPAzrYj0B8eIZ2zeEPM6NTR0O e7xittXEFlWroCerLmqd89PkNA0WejbV/CtSl4AYsTcwjq0zA0ipyodRFmO56aOPiAcK JCxA== X-Gm-Message-State: AOAM5326EL550LKbDxvT4fKCEI5MGVQ2JH81eULsHisxKKxnW+10O5ut W8pTz1EgD+bn7NU3w2/2G9jdSLtYOKWJVKlt8sI= X-Google-Smtp-Source: ABdhPJyH8O2sA80+4OzMnubt0waL4Hn/QTxAx7mnoH+qBv6e9PDtabH4hi1ltwlXupq0qOETUhNHGKngQ5zsfvOP/8s= X-Received: by 2002:a17:906:d931:: with SMTP id rn17mr880150ejb.308.1606931159480; Wed, 02 Dec 2020 09:45:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 2 Dec 2020 17:45:47 +0000 Message-ID: To: Florian Stascheck Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000f07d7805b57ed0c5" Subject: Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys From: george.banyard@gmail.com ("G. P. B.") --000000000000f07d7805b57ed0c5 Content-Type: text/plain; charset="UTF-8" On Wed, 2 Dec 2020 at 17:24, Florian Stascheck wrote: > Hello! > > With PHP8 released and the named arguments RFC being implemented, there's > now an inconsistency in how the spread operator works. > > Historically, the spread operator was first used in PHP 5.6 for arguments: > > function php56($a, $b) { > return $a + $b; > } > $test = [1, 2]; > php56(...$test) === 3; > > Then, with PHP 7.4, the spread operator was also introduced for array > literal syntax: > > $parts = ['apple', 'banana']; > $fruits = ['strawberry', ...$parts, 'grape']; > $fruits == ['strawberry', 'apple', 'banana', 'grape']; > > The RFC back then explicitly excluded [1] string keys, to make the > functioning of the spread operator consistent with how it's used for > function arguments. > > Now, in PHP8 we can do: > > function php8(int $a, int $b): int { > return $a + $b; > } > $test = ['b' => 40, 'a' => 2]; > php8(...$test) === 42; > > However, string keys in array literals are still not possible. So the > limitation that once was introduced for consistency now led to an > inconsistency. > > I suggest to allow string keys to also be used in array literals: > > $template = ['created_at' => time(), 'is_admin' => 1]; > $db_rows = [ > ['name' => 'Alice', 'email' => 'alice@example.org', ...$template], > ['name' => 'Bob', 'email' => 'bob@example.org', ...$template], > ]; > > What's your feedback on that? Do you see any obvious problems with that > approach? I searched through the archives and couldn't find this problem > being mentioned before. > > -Florian > > [1]: https://wiki.php.net/rfc/spread_operator_for_array#string_keys The reason why this has been deferred is because of which semantics should be used for duplicate string keys. Do we use the addition between two arrays semantics or the array_merge() semantics? See: https://3v4l.org/7QbWv As the previous RFC you linked initially wanted to use the array_merge() semantics. But due to contention was left out. Best regards, George P. Banyard --000000000000f07d7805b57ed0c5--