Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119825 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18976 invoked from network); 6 Apr 2023 13:04:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Apr 2023 13:04:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6355D180384 for ; Thu, 6 Apr 2023 06:04:00 -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=-0.7 required=5.0 tests=BAYES_05,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-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 ; Thu, 6 Apr 2023 06:04:00 -0700 (PDT) Received: by mail-wr1-f48.google.com with SMTP id e18so39439575wra.9 for ; Thu, 06 Apr 2023 06:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680786239; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pAUlWOWzPxg+LgkQv1zdfbKUEl7GVv3bVwXyM0oJEXs=; b=C5CAW2Pag4TXfmj5tFRIVCI5GZxiQXG2ccF1hcGeouEF74LHSLopxNm7JHjkwcr8YH qusc00fJP7oAWrDGF1p3PKDmsATtPi6EKREmHQrwSVObi258UawyAE9u+ALuF4hA6j2T nAZUJGoDA4PyTuEr1FXFwIZxVDgwCWbYkBFFjkRnsvzZCQLUFDd3nj2e3U3kL8ucIWLa tfBBhIPQkumBGRdAFKDVcr8FLktpGtG1SebjsWzJzwKs18Cm3a++4UfxWwwU7HdHMC/3 gukFja6CuCQrH/cu1G6t5J0aHVG9GoMzlxOu9+vrdBEGW5tbvI38rASDJr2IACN+0hH6 NG2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680786239; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pAUlWOWzPxg+LgkQv1zdfbKUEl7GVv3bVwXyM0oJEXs=; b=cZpjCoPgbop/8WfOBSZCAvfOx7NMwzhNbNHHXw1NCMmL0cv9Z4alisdrV2vpEBzO/A Xb49NvOcbY5Ouu64kjJiAMKoisi9Eg0vtepC2IKiKRaluMkpCVHaH4zvI5po0cHF0hQx 6arRs2Laa6BX8n45vhHtZlPmVP3oqn6sgIVXSWvYFovJKeRd6tUOU4gZv8V5hGsg+19M zfPjfHnkrDFMfpFd5W+a2xszG8YsE1kck84Oy87dSTTiuRK3s8CdxIejWuLdyIJUpMgk xybvfyJmPSNm3LgV6QJM647qHthtQa7LvefryXWOg15wqwRuTUAd5v5KQ93DYIRGn8jn W9mg== X-Gm-Message-State: AAQBX9eMlmpQiXbebYUxr8qPhPXPd5M+oFZbtnUCC2UH5XeHBdf6WbR8 bpS8AgI8KbJo4p73nyclak2IF5ibi++N+rPFgr4shjjg X-Google-Smtp-Source: AKy350acg4UNnINhcFgInVLHy4Prb56i0sLHPjVoaQnDDoe1YSOSmfBj5z4zAmzHR/a2X2KDWl3pj3RaPmBmtBcCPo0= X-Received: by 2002:a05:6000:1112:b0:2cf:e6d0:6379 with SMTP id z18-20020a056000111200b002cfe6d06379mr2133137wrw.6.1680786238644; Thu, 06 Apr 2023 06:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:d090:0:b0:2cf:ef90:c596 with HTTP; Thu, 6 Apr 2023 06:03:58 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Apr 2023 23:03:58 +1000 Message-ID: To: "Vorisek, Michael" Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000b2a87f05f8aa8ac1" Subject: Re: [PHP-DEV] Array spread append From: mickmackusa@gmail.com (mickmackusa) --000000000000b2a87f05f8aa8ac1 Content-Type: text/plain; charset="UTF-8" > > > * Are integer keys preserved? I'm assuming no, as otherwise it would > be the same as `$a + $b`. > > $arr[...] = $arr; > should be the same as > foreach ($arr as $v) { $arr[] = $v; } > > all other answers should be answered from this and consistency Since `$arr1[...] = $arr2;` should be consistent with `foreach ($arr2 as $v) { $arr1[] = $v; }` (or more succinctly with a bodiless loop: `foreach ($arr2 as $arr1[]);`. In this regard, it appears to destroy $arr2 keys while appending. So for cases with non-numeric keys that choke the spread operator within `array_push()`, then the bodiless loop isn't horrific. What I do find unsettling is that the spread operator in its current implementations always serves to unpack the payload that follows it (on its right side). However, in this new implementation, the three dots are entombed in square braces -- it would be inconsistent with the language. I think it would be more intuitive to implement an array "appending" functionality with "concatenating" syntax. The `.=` syntax already exists, but is forbidden from use on non-strings. If you want to implement this preexisting syntax as an array concatenation operator, then it is a blank slate -- you can decree whatever behaviors you wish for it without blurring what the combined operator does with strings. This opportunity is similar to how `+=` acts as an addition-assignment operator or an array union operator depending on context. I don't think I have an appetite for going down this road, but if so, I could imagine appending with `$all = $arr1 . $arr2 . $arr3;` The reason that I find this unsavory is probably because it becomes harder to intuit a data type by merely scanning code functionality. If the variable names aren't indicative and there is no type hinting, it will be hard to discern string variables from array variables without more context. I suppose my parting thought on this discussion is that the spread operator is just not the best tool for this job -- if this is a job worth doing at all. Mick --000000000000b2a87f05f8aa8ac1--