Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111823
MIME-Version: 1.0
References: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net>
 <CAF+90c8A7oWmM45poXj2goghCa00Jz3fiU7ud-aZgVwCfgXOzQ@mail.gmail.com>
 <20200903095840.4b83640d@mcmic-probook.opensides.be> <d5ed0ed1-40a6-f803-2260-ad984e42745d@fischer.name>
 <CAESVnVp2E3HW1P2BLA1sR+ZWCU-DtsD-jd61jaF7tsYh8XyG=A@mail.gmail.com>
In-Reply-To: <CAESVnVp2E3HW1P2BLA1sR+ZWCU-DtsD-jd61jaF7tsYh8XyG=A@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Thu, 3 Sep 2020 09:11:26 -0600
Message-ID: <CAAKU0unHyH5EwGhRqSaAwJBB+KWC6zLqiGHPKEBY4UwqDGOdHg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Markus Fischer <markus@fischer.name>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
From: internals@lists.php.net ("Levi Morrison via internals")

On Thu, Sep 3, 2020 at 8:32 AM Sara Golemon <pollita@php.net> wrote:
>
> On Thu, Sep 3, 2020 at 4:19 AM Markus Fischer <markus@fischer.name> 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?