Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111824 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18961 invoked from network); 3 Sep 2020 16:30:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Sep 2020 16:30:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1DF6C18053F for ; Thu, 3 Sep 2020 08:35:45 -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=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, MISSING_HEADERS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 ; Thu, 3 Sep 2020 08:35:44 -0700 (PDT) Received: by mail-oi1-f170.google.com with SMTP id z22so3566337oid.1 for ; Thu, 03 Sep 2020 08:35:44 -0700 (PDT) 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:cc; bh=8vuDbAxXe3wyWv2k7k0n9C2CNqt5b6hYWz1LoE278QE=; b=oR7cK97GQzCe+mWsAAekTNyfTBGeGKGenaF6hEXaww1VAcaNeDEqxLXwF4EzZET43G mJxHyIFFsA57dxeenMdLNjZeLxdRtKQ2jw3o2W9y/NhY0aucopFdAwwKqhsK6/m/d2F5 loQ/lKVsZQpfaW7dciNm1cEdO359pzp546cPLrXPIszbjjZVMg5nQiGknX/Bj7gRqssG MYVjg7AbkQ7kRo4NZdTOmLmmszP8MqGXdV/ZSPCr1YGrq/IkE4jWLyCBR+0/a8vDAHmS Le4WwcXx+KEQ8ZywkIo3Tcy1TzMJHrX7z9DXiiOVmKvYBxDNF3bwSKOpCNnSAPkrb3ZS pZEA== 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:cc; bh=8vuDbAxXe3wyWv2k7k0n9C2CNqt5b6hYWz1LoE278QE=; b=gvJlCzM8k1NM0RwOzmKD9PJiCctBZ3YU+tqKepBDxrAcMm3CuZtpVqQ7wJkkrpQayd HbLXjsZWpMgcybem8lnEwgHfDCb/YegG5YrhvQPwMAw+VG+8/U8sQjeOcymVPBtNdIBU v1DhVafIHeY/0TAQy8rQsRVrIZSFNIGqBHPwHNz+Ja4MfBoh//h19XPAGknjXtz7ZURd v8sYRHF6sL/HcwgqbsnOHuT+JXMHylBppUNGFPgJuuGmziKr+cHGM3Eh2wVmcw3RliSY R/Kx+obwGnrjBjJjseAQ5aB2kKv5ZFy2taudsT5xEALz//Yh5SKIr0ybyRg9FWBf+nwI h9MA== X-Gm-Message-State: AOAM531xZRFqW1oIt6qsRdZg5agtP7G184wgorVU35ek5+tMYbcEDhIT F8bxZh1pE1yiL4a2qNLr07M1V381IiQ0KIGNNX0KMA/AuEs= X-Google-Smtp-Source: ABdhPJyq4m8aWDHF9tiviGoloBlxDkSjO079aK1jajh9qY/ClW2AQQNPY9gfYYgbVCoWNkQXbdyBgUhCOUWSuG+Mm1U= X-Received: by 2002:aca:4ac2:: with SMTP id x185mr2375157oia.96.1599147342006; Thu, 03 Sep 2020 08:35:42 -0700 (PDT) MIME-Version: 1.0 References: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net> <20200903095840.4b83640d@mcmic-probook.opensides.be> In-Reply-To: Date: Thu, 3 Sep 2020 12:35:28 -0300 Message-ID: Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000043901605ae6a8173" Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values From: david.proweb@gmail.com (David Rodrigues) --00000000000043901605ae6a8173 Content-Type: text/plain; charset="UTF-8" Do you think that it could be proxied? I mean, optimize foreach (array_keys()...) syntax to not call array_keys() in fact, but a optimized version of foreach to handle key only. I don't know it opcache could do that, and if it already does. Em qui, 3 de set de 2020 12:12, Levi Morrison via internals < internals@lists.php.net> escreveu: > On Thu, Sep 3, 2020 at 8:32 AM Sara Golemon wrote: > > > > On Thu, Sep 3, 2020 at 4:19 AM Markus Fischer > wrote: > > > > > > I currently use foreach (array_keys($array) as $key) { ... } > > > > to avoid complains from code analysers on unused var, is it slower? > > > > > > one argument brought forward initially (sorry, can't find the email > > > right now) is the resource management: array_keys() has to create a > copy > > > [*] which might be an issue depending on the size of data. > > > > > > > > While I like the idea of more explicit syntax to show intent over a mere > > convention of $_ being an ignorable var, I do need to call out the > foreach > > (array_keys(...) argument as being a poor motivator. > > > > IF (and I heavily stress "if" here) this pattern is common among people > > trying to show explicit intent and IF it represents a noticeable > slowdown, > > then the solution for it is for the engine to optimize around that by > > transforming it during compile time. That lets us fix all usages > > instantaneously without user interaction, and more importantly it allows > > users to focus on their code being readable (and thereby maintainable) > > according to whatever coding standards they choose to apply. > > > > Again, that same argument is why I actually like the proposal overall. > Not > > because it's so much more performant, but because it empowers developers > to > > write code in a way that will be most readable and maintainable to them, > > should they happen to just not like the $_ unused var pattern (which is a > > legit thing to dislike). > > > > -Sara > > Question for those who know about opcache optimizations: is it > feasible to avoid fetching the current value if the value is otherwise > unused and the variable-variable features are not used either? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --00000000000043901605ae6a8173--