On Wed, 16 Sep 2020 at 04:00, Josh Bruce wrote:
>
> > * If PHP had either convention or special handling for _ or $_ as a
> “ignore this” destination, I wouldn’t have made the proposal. However, it
> doesn’t; _ can (apparently!) be a constant, and is also a function, and $_
> has no special
> * If PHP had either convention or special handling for _ or $_ as a “ignore
> this” destination, I wouldn’t have made the proposal. However, it doesn’t; _
> can (apparently!) be a constant, and is also a function, and $_ has no
> special handling (and I bet it’s actually used to contain
Hi everyone,
Apologies for not including context and responding to 40 emails all at once,
I’m not at a computer (and won’t be for a few weeks).
Given the comments I read in the thread, I wanted to make some key points that
I hope will clarify my intent behind the proposal:
* The primary
>
> In terms of readability, I'm more likely to do
> $keys = array_keys($array);
> foreach($keys as $key){
Fair point. I would too.
I have actually forgone even grabbing the keys and just using the loop without
touching value in the body.
Cheers,
Josh
--
PHP Internals - PHP Runtime
On Thu, Sep 3, 2020 at 12:05 PM Sara Golemon wrote:
> On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues
> wrote:
>
> > 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
On 02-09-2020 19:13, Nikita Popov wrote:
>
> Introducing special syntax for this has costs, both in terms of language
> complexity and in terms of implementation complexity. For example,
> implementing this feature will make foreach (whether or not the value is
> ignored) marginally slower,
On Thu, Sep 3, 2020, 7:05 PM Sara Golemon wrote:
> On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues
> wrote:
>
> > 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
On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues
wrote:
> 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
On Thu, Sep 3, 2020 at 5:35 PM David Rodrigues
wrote:
> > 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?
>
TBH, this sounds like the best
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
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
On 03-09-2020 15:07, Larry Garfield wrote:
>
> I agree here. _ is already a common pattern in other languages for a
> placeholder ignored variable. It's not a big jump for PHP static analyzers
> to start ignoring unused $_ variables, and it requires no language changes or
> formal standards.
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
On Thu, Sep 3, 2020, at 3:25 AM, Nikita Popov wrote:
> On Thu, Sep 3, 2020 at 10:19 AM Dik Takken wrote:
>
> > On 03-09-2020 09:38, Brent Roose wrote:
> > > Hi all
> > >
> > > I want to point out the use-case when you're using CS tools, static
> > analysers and IDEs: they report unused variables
-Original Message-
From: Dik Takken
Sent: Thursday, September 3, 2020 3:31 AM
To: Nikita Popov ; Mike Schinkel
Cc: John Bafford ; PHP internals
Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
On 02-09-2020 19:13, Nikita Popov wrote:
> Just like the fi
Hi,
On 03.09.20 09:58, Côme Chilliet wrote:
foreach ($iterable as $key => $_) { ... }
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
Von meinem iPhone gesendet
> Am 03.09.2020 um 09:39 schrieb Brent Roose :
>
> Hi all
>
> I want to point out the use-case when you're using CS tools, static analysers
> and IDEs: they report unused variables as errors. There are ways around those
> errors, but it's more convenient if
On Thu, Sep 3, 2020 at 10:19 AM Dik Takken wrote:
> On 03-09-2020 09:38, Brent Roose wrote:
> > Hi all
> >
> > I want to point out the use-case when you're using CS tools, static
> analysers and IDEs: they report unused variables as errors. There are ways
> around those errors, but it's more
On 03-09-2020 09:38, Brent Roose wrote:
> Hi all
>
> I want to point out the use-case when you're using CS tools, static analysers
> and IDEs: they report unused variables as errors. There are ways around those
> errors, but it's more convenient if there's language support. I'd say that
>
Le Wed, 2 Sep 2020 19:13:20 +0200,
Nikita Popov a écrit :
> Just like the first time this was discussed, I don't think this RFC makes a
> sufficient case on why we need explicit syntax for this. Just ignoring the
> value is an existing pattern that works across all PHP versions:
>
> foreach
Hi all
I want to point out the use-case when you're using CS tools, static analysers
and IDEs: they report unused variables as errors. There are ways around those
errors, but it's more convenient if there's language support. I'd say that
conceptually it's also more correct: if you're not using
> Iterating over just the keys is not a super common pattern and we already
have a reasonable way to do it (that is imho just as clear, and actually
more concise than the proposed "null" variant).
The reason I in my previous message suggested the engine optimization
for the "foreach
Hi!
> If it adds a micro-optimization, great, but allowing a developer to
> explicitly signal intent is the primary argument for adding void.
> IMO.
You can signal intent by using $_ or $dummy or whatever. You don't need
new language construct each time for each way of using or not using a
> On Sep 2, 2020, at 5:54 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>>> In theory, this should be a general performance win any time one
>>> needs to iterate over only the keys of an iterable, because it does
>>> not require the use of an O(n) iteration and building of the array
>>> that
Hi Benas IML,
> I'd also like to mention that other languages don't have any kind of
> syntactic sugar/special syntax for iterating over keys. That is achieved
> using a function though.
That's not true, Golang has iterating over keys by default and a more verbose
syntax to iterate over values.
Hi!
>> In theory, this should be a general performance win any time one
>> needs to iterate over only the keys of an iterable, because it does
>> not require the use of an O(n) iteration and building of the array
>> that array_keys() would, plus it works on non-array types (such as
>> generators
On Wed, 2 Sep 2020, 21:54 Dik Takken, wrote:
> On 02-09-2020 21:31, Dik Takken wrote:
> > Even if we decide that it is not worth the trouble for foreach loops,
> > there are other cases where this new syntax can work well. Array
> > destructuring has already been mentioned.
>
> Replying to
> On Sep 2, 2020, at 12:05 PM, Michael Voříšek - ČVUT FEL
> wrote:
>
> I like "void", as "null" can be ambiguous.
>
> Imagine function example($a = 'default value 1', $b = 'default value 2') {}
>
> With "void", we can allow skipping arguments in advance to the default
> pamameter value
On 02-09-2020 21:31, Dik Takken wrote:
> Even if we decide that it is not worth the trouble for foreach loops,
> there are other cases where this new syntax can work well. Array
> destructuring has already been mentioned.
Replying to myself: It just occurred to me that array destructuring
already
On 02-09-2020 19:13, Nikita Popov wrote:
> Just like the first time this was discussed, I don't think this RFC makes a
> sufficient case on why we need explicit syntax for this. Just ignoring the
> value is an existing pattern that works across all PHP versions:
>
> foreach ($iterable as $key
On Wed, Sep 2, 2020 at 1:13 PM Nikita Popov wrote:
> On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel wrote:
>
> > This is a new thread for John Bafford's RFC which he mentioned on another
> > thread, see below:
> >
> > https://wiki.php.net/rfc/foreach_void <
> >
+1.
I'd also like to mention that other languages don't have any kind of
syntactic sugar/special syntax for iterating over keys. That is achieved
using a function though.
This proposal to me seems a bit like the "return if/guard" RFC i. e. I see
no value in it.
On Wed, Sep 2, 2020, 8:13 PM
On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel wrote:
> This is a new thread for John Bafford's RFC which he mentioned on another
> thread, see below:
>
> https://wiki.php.net/rfc/foreach_void <
> https://wiki.php.net/rfc/foreach_void>
>
Just like the first time this was discussed, I don't think
I like "void", as "null" can be ambiguous.
Imagine function example($a = 'default value 1', $b = 'default value 2')
{}
With "void", we can allow skipping arguments in advance to the default
pamameter value like example(void, 'test');.
With kind regards / Mit freundlichen Grüßen / S
On Wed, 2 Sep 2020 at 18:58, Ben Ramsey wrote:
>
> > On Sep 2, 2020, at 11:14, Lester Caine wrote:
> >
> > On 02/09/2020 15:31, Thomas Bley wrote:
> >> I'd also like to propose to use null:
> >> [null, null, $username] = getUserData();
> >> foreach ($source as $key => null) {}
> >
> > Exactly
> On Sep 2, 2020, at 11:14, Lester Caine wrote:
>
> On 02/09/2020 15:31, Thomas Bley wrote:
>> I'd also like to propose to use null:
>> [null, null, $username] = getUserData();
>> foreach ($source as $key => null) {}
>
> Exactly what null is designed for ...
I second (or third) `null`.
On Wed, Sep 2, 2020 at 9:31 AM Thomas Bley wrote:
> Hello,
>
> I'd also like to propose to use null:
>
> [null, null, $username] = getUserData();
>
> foreach ($source as $key => null) {}
>
>
These both look like great, expressive syntaxes. No new keywords, no major
change to existing idioms,
On 02/09/2020 15:31, Thomas Bley wrote:
I'd also like to propose to use null:
[null, null, $username] = getUserData();
foreach ($source as $key => null) {}
Exactly what null is designed for ...
--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
Hello,
I'd also like to propose to use null:
[null, null, $username] = getUserData();
foreach ($source as $key => null) {}
Regards
Thomas
> David Rodrigues hat am 02.09.2020 16:24 geschrieben:
>
>
> I think "void" is a good solution and is very clear, compared to "_".
>
> [void, void,
I think "void" is a good solution and is very clear, compared to "_".
[void, void, $username] = getUserData();
Atenciosamente,
David Rodrigues
Em qua., 2 de set. de 2020 às 10:57, Dik Takken
escreveu:
> On 02-09-2020 15:35, Chase Peeler wrote:
> > Isn't the underscore an alias for
On 02-09-2020 15:35, Chase Peeler wrote:
> Isn't the underscore an alias for gettext()?
You are right, it is. Now this does not necessarily mean that underscore
cannot be used for ignored variables. Depending on the context in which
it is used an underscore may or may not be ambiguous.
Since we
On Wed, Sep 2, 2020 at 9:16 AM Josh Bruce wrote:
>
> > On Sep 2, 2020, at 6:27 AM, Dik Takken wrote:
> >
> > On 02-09-2020 12:48, Olle Härstedt wrote:
> >> An alternative syntax would be
> >>
> >>foreach($iterable as $key => _) { ... }
> >>
> >> Using underscore as a way to signal "I don't
> On Sep 2, 2020, at 6:27 AM, Dik Takken wrote:
>
> On 02-09-2020 12:48, Olle Härstedt wrote:
>> An alternative syntax would be
>>
>>foreach($iterable as $key => _) { ... }
>>
>> Using underscore as a way to signal "I don't care about this value".
>> Same could be possible with list
On 02-09-2020 12:48, Olle Härstedt wrote:
> An alternative syntax would be
>
> foreach($iterable as $key => _) { ... }
>
> Using underscore as a way to signal "I don't care about this value".
> Same could be possible with list destructoring, like
>
> [_, _, $something] = foo();
>
>
An alternative syntax would be
foreach($iterable as $key => _) { ... }
Using underscore as a way to signal "I don't care about this value".
Same could be possible with list destructoring, like
[_, _, $something] = foo();
This syntax comes from OCaml. Possibly other languages, too? Not
45 matches
Mail list logo