Hi Björn,
On Wed, Jun 29, 2022 at 8:09 PM Björn Larsson via internals <
internals@lists.php.net> wrote:
> Would it be an option to include a "Future scope" with the features:
> - Explicit capture that list only the variables to be captured by value
> or reference, nothing else.
> - Extending the
Hi Rowan,
Since this still has a small chance of breaking existing code, we preferred
to exclude arrow functions from this change, for now. We have added this in
Future Scope. This is something we could do in a follow-up RFC.
Regards,
Hi Guilliam,
Thank you for noticing.
The PR is now fully in sync with the RFC (no arrow function changes, no
explicit use support).
The RFC also now clarifies that arrow functions are not changed by the RFC.
On Thu, Jun 30, 2022 at 7:37 PM Arnaud Le Blanc wrote:
>
> On jeudi 30 juin 2022 18:29:44 CEST Guilliam Xavier wrote:
> > Ah? Sorry, I had interpreted
> > https://github.com/php/php-src/pull/8330/files#diff-85701127596aca0e597bd796
> > 1b5d59cdde4f6bb3e2a109a22be859ab7568b4d2R7318-R7320 as "captur
On 30/06/2022 18:37, Arnaud Le Blanc wrote:
On jeudi 30 juin 2022 18:29:44 CEST Guilliam Xavier wrote:
Ah? Sorry, I had interpreted
https://github.com/php/php-src/pull/8330/files#diff-85701127596aca0e597bd796
1b5d59cdde4f6bb3e2a109a22be859ab7568b4d2R7318-R7320 as "capture the
*minimal* set of va
On jeudi 30 juin 2022 18:29:44 CEST Guilliam Xavier wrote:
> Ah? Sorry, I had interpreted
> https://github.com/php/php-src/pull/8330/files#diff-85701127596aca0e597bd796
> 1b5d59cdde4f6bb3e2a109a22be859ab7568b4d2R7318-R7320 as "capture the
> *minimal* set of variables for *both* arrow functions and
On Thu, Jun 30, 2022 at 5:57 PM Arnaud Le Blanc wrote:
>
> Hi,
>
> On jeudi 30 juin 2022 16:18:44 CEST Robert Landers wrote:
> > Are
> > optimizations going to be applied to single-line arrow functions (I
> > didn't see that in the RFC, but I admittedly didn't look that hard and
> > I vaguely reme
On Thu, Jun 30, 2022 at 5:47 PM Guilliam Xavier
wrote:
>
> On Thu, Jun 30, 2022 at 3:26 PM Dan Ackroyd wrote:
> >
> > Hi Rowan,
> >
> > Rowan wrote:
> > > For that to work, it would require the variable to be captured by
> > > reference, not value.
> > > ...
> > > The only way for it to work woul
Hi,
On jeudi 30 juin 2022 16:18:44 CEST Robert Landers wrote:
> Are
> optimizations going to be applied to single-line arrow functions (I
> didn't see that in the RFC, but I admittedly didn't look that hard and
> I vaguely remember reading something about it in one of these
> threads)? If so, it w
On Thu, Jun 30, 2022 at 3:26 PM Dan Ackroyd wrote:
>
> Hi Rowan,
>
> Rowan wrote:
> > For that to work, it would require the variable to be captured by
> > reference, not value.
> > ...
> > The only way for it to work would be using capture by reference (not
> > supported by the proposed short syn
On 30/06/2022 14:25, Dan Ackroyd wrote:
With automatic capturing of variables, for the code example I gave the
user would want the variable to be captured, and to them it looks like
it should be, but because of an optimization it is not.
Please look again at the detailed explanation I gave, an
On Thu, Jun 30, 2022 at 3:26 PM Dan Ackroyd wrote:
>
> Hi Rowan,
>
> Rowan wrote:
> > For that to work, it would require the variable to be captured by
> > reference, not value.
> > ...
> > The only way for it to work would be using capture by reference (not
> > supported by the proposed short syn
Hi Rowan,
Rowan wrote:
> For that to work, it would require the variable to be captured by
> reference, not value.
> ...
> The only way for it to work would be using capture by reference (not
> supported by the proposed short syntax):
I wrote about this before. Some of the words in the RFC are, i
On 30/06/2022 11:29, Arnaud Le Blanc wrote:
I feel that the RAII pattern aka SBRM / Scope-Bound Resource Management is not
relevant in PHP context, and I don't believe that it's commonly used in PHP or
in garbage collected language.
I've used a simple version of the pattern effectively to imp
Hi,
On jeudi 30 juin 2022 00:31:44 CEST Dan Ackroyd wrote:
> On Wed, 29 Jun 2022 at 18:30, Larry Garfield wrote:
> > The conversation has died down, so we'll be opening the vote for this
> > tomorrow.
> I think I've just thought of a problem with the optimization bit of
> 'not capturing variables
On Thu, Jun 30, 2022 at 11:20 AM Robert Landers
wrote:
>
> On Thu, Jun 30, 2022 at 10:19 AM Rowan Tommins
> wrote:
> >
> > On 29/06/2022 23:31, Dan Ackroyd wrote:
> > > Imagine some code that looks like this:
> > >
> > > // Acquire some resource e.g. an exclusive lock.
> > > $some_resource = acq
On 30/06/2022 10:20, Robert Landers wrote:
I think their suggested code would work (at least currently in PHP) by
the simple fact they would increase the reference count on that
object/resource until they set it as null. However, with the
"optimization," the reference count will never be incremen
On Thu, Jun 30, 2022 at 10:19 AM Rowan Tommins wrote:
>
> On 29/06/2022 23:31, Dan Ackroyd wrote:
> > Imagine some code that looks like this:
> >
> > // Acquire some resource e.g. an exclusive lock.
> > $some_resource = acquire_some_resource();
> >
> > $fn = fn () {
> > // Free that resource
On 29/06/2022 23:31, Dan Ackroyd wrote:
Imagine some code that looks like this:
// Acquire some resource e.g. an exclusive lock.
$some_resource = acquire_some_resource();
$fn = fn () {
// Free that resource
$some_resource = null;
}
// do some stuff that assumes the exclusive
// lock
On Wed, 29 Jun 2022 at 18:30, Larry Garfield wrote:
>
> The conversation has died down, so we'll be opening the vote for this
> tomorrow.
I think I've just thought of a problem with the optimization bit of
'not capturing variables if they are written to before being used
inside the closure'.
Im
Den 2022-06-29 kl. 19:30, skrev Larry Garfield:
On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:
Last year, Nuno Maduro and I put together an RFC for combining the
multi-line capabilities of long-closures with the auto-capture
compactness of short-closures. That RFC didn't fully go to co
On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:
> Last year, Nuno Maduro and I put together an RFC for combining the
> multi-line capabilities of long-closures with the auto-capture
> compactness of short-closures. That RFC didn't fully go to completion
> due to concerns over the perfor
On Wed, Jun 15, 2022, at 7:05 AM, Guilliam Xavier wrote:
>> > > Because variables are captured by-value, Short Closures can not have
>> > > unintended side effects.
>> >
>> > Those statements are true for scalar values. They are not true for objects:
>>
>> This is shown in the "No unintended side-e
> > > Because variables are captured by-value, Short Closures can not have
> > > unintended side effects.
> >
> > Those statements are true for scalar values. They are not true for objects:
>
> This is shown in the "No unintended side-effects" section of the RFC.
I'm confused by the last example:
Den 2022-06-13 kl. 14:57, skrev Arnaud Le Blanc:
On samedi 11 juin 2022 23:14:28 CEST Rowan Tommins wrote:
My main concern is summed up accidentally by your choice of subject line
for this thread: is the proposal to add *short closure syntax* or is it
to add *auto-capturing closures*?
The prop
(Sorry for double reply, hit send too soon)
On 14/06/2022 12:18, Arnaud Le Blanc wrote:
Your example uses isset(), which is valid code in most circumstances, but as
you said it's not particularly good code. Do you have other examples that come
to mind ?
There is plenty of code out there in th
On 14/06/2022 12:18, Arnaud Le Blanc wrote:
- The closure mutates a value accessed through a captured variable. Mutable
values include objects and resources, but NOT scalars or arrays (since they
are copy-on-write).
It's not something that is used very often, so is often forgotten or
ignored,
> On Jun 13, 2022, at 1:39 PM, Rowan Tommins wrote:
>
> On 13/06/2022 14:52, Larry Garfield wrote:
>>> That's one perspective. The other perspective is that the proposal is to
>>> extend closure syntax to support automatic capture.
>> As noted before, this is a distinction without a difference
On lundi 13 juin 2022 15:36:26 CEST Rowan Tommins wrote:
> > Auto-capture in PHP is by-value. This makes this impossible. It also makes
> > explicit declarations non-necessary and much less useful.
> >
> > Live-variable analysis is mentioned in as part of implementation details.
> > It should not
Hi Dan,
On lundi 13 juin 2022 19:49:10 CEST Dan Ackroyd wrote:
> > Auto-capture in PHP is by-value. This makes this impossible. It also makes
> > explicit declarations non-necessary and much less useful.
>
> Separating off some pedantism from the hopefully constructive comment,
>
> I think some
Hi Larry, Arnaud,
On Mon, 13 Jun 2022 at 13:57, Arnaud Le Blanc wrote:
>
> Auto-capture in PHP is by-value. This makes this impossible. It also makes
> explicit declarations non-necessary and much less useful.
>
Separating off some pedantism from the hopefully constructive comment,
I think some
On 13/06/2022 14:52, Larry Garfield wrote:
That's one perspective. The other perspective is that the proposal is to
extend closure syntax to support automatic capture.
As noted before, this is a distinction without a difference.
It's a difference in focus which is very evident in some of the
Hi Arnaud,
Arnaud Le Blanc wrote:
>
> Following your comment, I have clarified a few things in the "Auto-capture
> semantics" section. This includes a list of way in which these effects can be
> observed. These are really marginal cases that are not relevant for most
> programs.
Cool, thanks.
>
On Mon, Jun 13, 2022, at 8:36 AM, Rowan Tommins wrote:
> On 13/06/2022 13:57, Arnaud Le Blanc wrote:
>> The proposal is to extend the Arrow Functions syntax so that it allows
>> multiple statements.
>
>
> That's one perspective. The other perspective is that the proposal is to
> extend closure syn
On 13/06/2022 13:57, Arnaud Le Blanc wrote:
The proposal is to extend the Arrow Functions syntax so that it allows
multiple statements.
That's one perspective. The other perspective is that the proposal is to
extend closure syntax to support automatic capture.
Currently the `use()` syntax
On 13/06/2022 13:29, Arnaud Le Blanc wrote:
Following your comment, I have clarified a few things in the "Auto-capture
semantics" section. This includes a list of way in which these effects can be
observed. These are really marginal cases that are not relevant for most
programs.
I'm not sure I
On samedi 11 juin 2022 23:14:28 CEST Rowan Tommins wrote:
> My main concern is summed up accidentally by your choice of subject line
> for this thread: is the proposal to add *short closure syntax* or is it
> to add *auto-capturing closures*?
The proposal is to extend the Arrow Functions syntax so
On dimanche 12 juin 2022 20:05:02 CEST Dan Ackroyd wrote:
> On Thu, 9 Jun 2022 at 17:34, Larry Garfield wrote:
> > That RFC didn't fully go to completion due to concerns over the
> > performance impact
> I don't believe that is an accurate summary. There were subtle issues
> in the previous RFC th
On lundi 13 juin 2022 12:28:17 CEST Robert Landers wrote:
> From a maintainer and code review aspect, I prefer the longer syntax
> because it is 100% clear on which variables are being closed over and
> utilized in the anonymous function. fn($x) => $x + $y is pretty clear
> that $y is being pulled
On Mon, Jun 13, 2022 at 11:36 AM Arnaud Le Blanc wrote:
>
> On dimanche 12 juin 2022 19:54:06 CEST Mark Baker wrote:
> > Did many of those closures use "pass by reference" in the use clause,
> > because that's one real differentiator between traditional closures and
> > short lambdas. There's also
On dimanche 12 juin 2022 19:54:06 CEST Mark Baker wrote:
> Did many of those closures use "pass by reference" in the use clause,
> because that's one real differentiator between traditional closures and
> short lambdas. There's also the fact that use values are bound at the
> point where the closur
On Sun, Jun 12, 2022, at 3:44 PM, Rowan Tommins wrote:
> On 12/06/2022 18:21, Larry Garfield wrote:
>> The primary target of this RFC is people writing 2-4 line closures that
>> import 1-2 variables
>
>
> The first half of that sentence I was expecting - although as I've
> already said, I think t
On 12/06/2022 18:21, Larry Garfield wrote:
The primary target of this RFC is people writing 2-4 line closures that import
1-2 variables
The first half of that sentence I was expecting - although as I've
already said, I think the chosen syntax suggests strongly that the RFC
is really targeti
On Sun, Jun 12, 2022, at 12:54 PM, Mark Baker wrote:
> On 12/06/2022 19:21, Larry Garfield wrote:
>> On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:
>>
>> A little data:
>>
>> I used Nikita's project analyzer on the top 1000 projects to get a rough
>> sense of how long-closures are used no
On Sun, Jun 12, 2022 at 6:55 PM Rowan Tommins
wrote:
>
> >It seems to me that you agree that there is a chance the proposed syntax
> is
> >going to be perceived as better and people will not want to use the old
> >syntax anymore and that makes you not want to accept the RFC.
>
> No, it makes me w
On Thu, 9 Jun 2022 at 17:34, Larry Garfield wrote:
>
> That RFC didn't fully go to completion due to concerns over the performance
> impact
I don't believe that is an accurate summary. There were subtle issues
in the previous RFC that should have been addressed. Nikita Popov
wrote in https://new
On 12/06/2022 19:21, Larry Garfield wrote:
On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:
A little data:
I used Nikita's project analyzer on the top 1000 projects to get a rough sense of how
long-closures are used now. All usual caveats apply about such survey data. I was
specifica
On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:
> Last year, Nuno Maduro and I put together an RFC for combining the
> multi-line capabilities of long-closures with the auto-capture
> compactness of short-closures. That RFC didn't fully go to completion
> due to concerns over the perfor
On 12 June 2022 16:22:15 BST, Deleu wrote:
>> I honestly don't think this is how it will be perceived. If this syntax
>> is approved, people will see "fn" as the "new, better way" and
>> "function" as the "old, annoying way".
>>
>
>And to me that's not an argument to deny what people want.
I neve
On Sun, Jun 12, 2022 at 2:29 PM Rowan Tommins
wrote:
> On 11/06/2022 23:01, Deleu wrote:
> > The RFC does mention that the existing Anonymous Function Syntax
> > remains untouched and will not be deprecated. Whether the new syntax
> > is better for nearly all closures will be a personal choice.
>
On 12/06/2022 03:01, Larry Garfield wrote:
... users don't "learn to recognize" that a loop doesn't hide all variables
from the parent
scope; it would be very peculiar if it did.
There are languages that do, however. Some languages have block-scoped
variables by default (such as Rust), or par
On 11/06/2022 23:01, Deleu wrote:
The RFC does mention that the existing Anonymous Function Syntax
remains untouched and will not be deprecated. Whether the new syntax
is better for nearly all closures will be a personal choice.
I honestly don't think this is how it will be perceived. If this
> On Jun 11, 2022, at 10:01 PM, Larry Garfield wrote:
>
> On Sat, Jun 11, 2022, at 4:14 PM, Rowan Tommins wrote:
>> On 09/06/2022 17:34, Larry Garfield wrote:
>>> Last year, Nuno Maduro and I put together an RFC for combining the
>>> multi-line capabilities of long-closures with the auto-capture
On Sat, Jun 11, 2022, at 4:14 PM, Rowan Tommins wrote:
> On 09/06/2022 17:34, Larry Garfield wrote:
>> Last year, Nuno Maduro and I put together an RFC for combining the
>> multi-line capabilities of long-closures with the auto-capture compactness
>> of short-closures ... Arnaud Le Blanc has now
On Sat, Jun 11, 2022, at 5:01 PM, Deleu wrote:
> On Sat, Jun 11, 2022 at 11:14 PM Rowan Tommins
> wrote:
>
>> On 09/06/2022 17:34, Larry Garfield wrote:
>> > Last year, Nuno Maduro and I put together an RFC for combining the
>> multi-line capabilities of long-closures with the auto-capture compact
On Sat, Jun 11, 2022 at 11:14 PM Rowan Tommins
wrote:
> On 09/06/2022 17:34, Larry Garfield wrote:
> > Last year, Nuno Maduro and I put together an RFC for combining the
> multi-line capabilities of long-closures with the auto-capture compactness
> of short-closures ... Arnaud Le Blanc has now pi
On 09/06/2022 17:34, Larry Garfield wrote:
Last year, Nuno Maduro and I put together an RFC for combining the multi-line
capabilities of long-closures with the auto-capture compactness of
short-closures ... Arnaud Le Blanc has now picked up the flag with an improved
implementation ... The RFC
On Thu, Jun 9, 2022 at 9:39 PM Marco Pivetta wrote:
> Hey Nikita,
>
> On Thu, 9 Jun 2022 at 21:35, Nikita Popov wrote:
>
>> On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta wrote:
>>
>>>
>>> On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
>>>
On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc
>
Hey Nikita,
On Thu, 9 Jun 2022 at 21:35, Nikita Popov wrote:
> On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta wrote:
>
>>
>> On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
>>
>>> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc
>>> wrote:
>>>
> Would that allow us to get rid of `static fn
On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta wrote:
>
> On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
>
>> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc
>> wrote:
>>
>>> Hi,
>>>
>>> On jeudi 9 juin 2022 18:46:53 CEST Marco Pivetta wrote:
>>> > ## nesting these functions within each other
>>
On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc
> wrote:
>
>> Hi,
>>
>> On jeudi 9 juin 2022 18:46:53 CEST Marco Pivetta wrote:
>> > ## nesting these functions within each other
>> >
>> > What happens when/if we nest these functions? Take this mi
On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc wrote:
> Hi,
>
> On jeudi 9 juin 2022 18:46:53 CEST Marco Pivetta wrote:
> > ## nesting these functions within each other
> >
> > What happens when/if we nest these functions? Take this minimal example:
> >
> > ```php
> > $a = 'hello world';
> >
> >
On Thu, Jun 9, 2022, at 1:36 PM, Michał Marcin Brzuchalski wrote:
> Hi Larry,
>
> czw., 9 cze 2022 o 18:34 Larry Garfield napisał(a):
>
>> Last year, Nuno Maduro and I put together an RFC for combining the
>> multi-line capabilities of long-closures with the auto-capture compactness
>> of short-cl
Hi Larry,
czw., 9 cze 2022 o 18:34 Larry Garfield napisał(a):
> Last year, Nuno Maduro and I put together an RFC for combining the
> multi-line capabilities of long-closures with the auto-capture compactness
> of short-closures. That RFC didn't fully go to completion due to concerns
> over the
Hi,
On jeudi 9 juin 2022 18:46:53 CEST Marco Pivetta wrote:
> ## nesting these functions within each other
>
> What happens when/if we nest these functions? Take this minimal example:
>
> ```php
> $a = 'hello world';
>
> (fn () {
> (fn () {
> echo $a;
> })();
> })();
> ```
Cap
Hey Larry,
On Thu, 9 Jun 2022 at 18:34, Larry Garfield wrote:
> Last year, Nuno Maduro and I put together an RFC for combining the
> multi-line capabilities of long-closures with the auto-capture compactness
> of short-closures. That RFC didn't fully go to completion due to concerns
> over the
66 matches
Mail list logo
