Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On vendredi 1 juillet 2022 16:04:30 CEST Larry Garfield wrote: > Greetings, Internalians. > > The vote for auto-capture closures is now open. It will run until 15 July. > > https://wiki.php.net/rfc/auto-capture-closure Hi Internals, The RFC has been declined with a vote of 27 in favor and 16 against. Thank you for the votes and the feedbacks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On mardi 5 juillet 2022 09:27:34 CEST Marco Pivetta wrote: > This is fine, but it creates a bidirectional dependency between components > where the dependency graph was previously (in theory) acyclic. > > This will become "someone else's problem" I don't think that the Optimizer conceptually depends on the Compiler currently. It does include `Zend/zend_compile.h`, but that's only for the types defined in this header. It needs these types because its responsibility is to transform data structures produced by the compiler (op_arrays), or in this case, to produce meta data about these structures. These types can be trivially moved to an other header. It doesn't call any compiler code. Also, this doesn't introduces circular includes involving Zend/zend_compile.h. Does it seems ok to you ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On Mon, 4 Jul 2022, 19:15 Arnaud Le Blanc, wrote: > > Important to note how `Zend/zend_compile.c` now depends on `Optimizer/`, > > which is a potential design issue. > > The Optimizer was moved to `Zend/Optimizer` earlier so that in the long > term > it could be used by the compiler pipeline directly (rather than as part of > caching). > Thanks for clarifying! > > There are clear benefits in reusing the Optimizer here. Duplicating or > reimplementing live variable analysis would increase maintenance cost, > whereas > by reusing the Optimizer's implementation we take profit of a fast and > well > tested implementation. > > Greets, > This is fine, but it creates a bidirectional dependency between components where the dependency graph was previously (in theory) acyclic. This will become "someone else's problem"
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
Hi, On lundi 4 juillet 2022 11:47:03 CEST Nicolas Grekas wrote: > I'm just wondering if there could be a way to enable the auto-capture > optimization for arrow functions. Having three kinds of rules for capturing > feels too much, especially when there are that subtles for short closures. > Maybe a deprecation could be possible for affected arrow functions? Yes. I will propose this after this RFC. This is not included in the RFC because the optimization rarely have an impact on Arrow Functions (they rarely bind variables). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
Hi, On lundi 4 juillet 2022 12:04:59 CEST Marco Pivetta wrote: > I ended up voting NO due to the fact that there is no mention of `$this` > behavior changes ( https://externals.io/message/117888#117889 ) : I also > disagree with NikiC's stance on this being the same construct as before ( > https://externals.io/message/117888#117897 ), so I really wanted to get rid > of this constant memleak risk that we have in closures. I should have made > my stance stronger, instead of letting the discussion thread die, but time > is what it is. Forgot to add this in Future Scope, sorry. The RFC does NOT change the behavior of `$this`, so as to keep it small. This is something I personally want, but it can be done after this RFC, and the change could be applied to all function kinds. > Unclear (to me) after looking at > https://gist.github.com/arnaud-lb/d9adfbf786ce9e37c7157b0f9c8d8e13, is > whether the optimizations are applied at compile time. It looks like the > changes are inside the `Zend/Optimizer/`, and `zend_compile.c`, so perhaps > the benchmarks are probably just worded in a confusing way. Sorry for the confusion. I confirm that the optimizations are applied at compile time. The benchmarks measure the runtime effect of these optimizations. > Important to note how `Zend/zend_compile.c` now depends on `Optimizer/`, > which is a potential design issue. The Optimizer was moved to `Zend/Optimizer` earlier so that in the long term it could be used by the compiler pipeline directly (rather than as part of caching). There are clear benefits in reusing the Optimizer here. Duplicating or reimplementing live variable analysis would increase maintenance cost, whereas by reusing the Optimizer's implementation we take profit of a fast and well tested implementation. Greets, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
I ended up voting NO due to the fact that there is no mention of `$this` behavior changes ( https://externals.io/message/117888#117889 ) : I also disagree with NikiC's stance on this being the same construct as before ( https://externals.io/message/117888#117897 ), so I really wanted to get rid of this constant memleak risk that we have in closures. I should have made my stance stronger, instead of letting the discussion thread die, but time is what it is. The idea is interesting, but I'd rather keep using the old construct until the new one doesn't have the same pitfalls, and I'm fine with having to type more characters for the time being. The optimizations applied to the new proposal can probably be experimented on short closures meanwhile (for PHP 9.0, since there will certainly be the "edge of edgecases" somewhere), since there is hope for perf improvements there too. Unclear (to me) after looking at https://gist.github.com/arnaud-lb/d9adfbf786ce9e37c7157b0f9c8d8e13, is whether the optimizations are applied at compile time. It looks like the changes are inside the `Zend/Optimizer/`, and `zend_compile.c`, so perhaps the benchmarks are probably just worded in a confusing way. Important to note how `Zend/zend_compile.c` now depends on `Optimizer/`, which is a potential design issue. Greets, Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/ On Fri, 1 Jul 2022 at 16:05, Larry Garfield wrote: > Greetings, Internalians. > > The vote for auto-capture closures is now open. It will run until 15 July. > > https://wiki.php.net/rfc/auto-capture-closure > > -- > Larry Garfield > la...@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
Hi there, Greetings, Internalians. > > The vote for auto-capture closures is now open. It will run until 15 July. > > https://wiki.php.net/rfc/auto-capture-closure > Thanks for the RFC, I voted yes as I think the optimized auto-capturing logic is sound. Having "function()" still be a first-class citizen is also important to me as there are cases where one might prefer the explicit nature of capturing, so I join Rowan on this "rhetoric" topic. I'm just wondering if there could be a way to enable the auto-capture optimization for arrow functions. Having three kinds of rules for capturing feels too much, especially when there are that subtles for short closures. Maybe a deprecation could be possible for affected arrow functions? Nicolas
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On 01/07/2022 15:04, Larry Garfield wrote: Greetings, Internalians. The vote for auto-capture closures is now open. It will run until 15 July. https://wiki.php.net/rfc/auto-capture-closure I have voted No, because although I am more-or-less convinced that auto-capture is a useful feature, I don't think this is the right syntax for it. - Having "fn" and "function" mean almost the same thing, but with such an important difference, feels like a WTF waiting to happen. - The RFC seems to take for granted that shorter syntax is better, calling explicit syntax "noise"; but in that case PHP contains a lot of "noise", and I'm not convinced that removing it would be a good thing. - This emphasis also implies that auto-capture is a near-universal improvement over explicit capture, rather than an alternative on equal footing: it is the version that deserves the very best syntax possible. I remain unconvinced by this. - Unlike other languages, PHP normally relies on opting into scope imports (global, $this->, etc), so lacks a mechanism to opt out and declare a variable as local (var, let, etc). The proposed syntax offers neither opt-in nor opt-out, relying on the implementation to do the right thing automatically ... most of the time. To re-iterate, I am not opposed to the feature in principle, but would have loved to see a more open exploration of different syntax options. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
>But do any of them auto-capture by value?
in c++ it's optional if you want to capture-by-value or
capture-by-reference, [&]()->void{...}(); captures everything by reference
and [=]()mutable->void{...}(); captures everything by value
> I think that's still explicit
fair assessment
On Sat, 2 Jul 2022 at 05:02, Anton Smirnov wrote:
> On Fri, 2022-07-01 at 16:11 +0200, Hans Henrik Bergan wrote:
> > > As far as we are aware, only two languages in widespread use
> > > require variables to be explicitly closed over: PHP and C++. All
> > > other major languages capture implicitly, as is proposed here.
>
> But do any of them auto-capture by value?
>
> > to be fair to c++, it supports [&] to capture everything, like
> > int a=1,b=2,c=3;[&]()->void{std::cout << a << b << c;}();
>
> I think that's still explicit
>
> --
> Anton
>
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On Fri, 2022-07-01 at 16:11 +0200, Hans Henrik Bergan wrote:
> > As far as we are aware, only two languages in widespread use
> > require variables to be explicitly closed over: PHP and C++. All
> > other major languages capture implicitly, as is proposed here.
But do any of them auto-capture by value?
> to be fair to c++, it supports [&] to capture everything, like
> int a=1,b=2,c=3;[&]()->void{std::cout << a << b << c;}();
I think that's still explicit
--
Anton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On Fri, 1 Jul 2022 at 15:05, Larry Garfield wrote:
>
> The vote for auto-capture closures is now open. It will run until 15 July.
Voting no as:
i) changes in the implementation need more than 1.5 hours discussion
between that change and the voting opening.
ii) The inconsistency of capturing rules between this RFC and arrow
functions are "not obviously" the correct choice. And definitely need
more than 90 minutes of thinking about.
iii) Some of the phrases in the RFC are still just not true.
"Capture is by-value, no unintended side-effects"
"A by-value capture means that it is not possible to modify any
variables from the outer scope"
"Because variables are bound by-value, the confusing behaviors often
associated with closures do not exist."
They are true for scalar values, but not for objects.
RFCs need to be written clearly so that people don't get the wrong
impression if the don't read every single word.
btw for my concerns about object capturing and RAII, the manual could
probably say something like:
> If you want to ensure an object is captured you can either assign it to
> itself:
>
> $foo = $foo;
>
> Or create an empty function:
>
> function ensure_variables_stays_alive(mixed $variable)
> {
>/* function is intentionally blank */
> }
>
> and call that function with the variable you want to stay alive inside the
> closure.
But again, this is "not obviously" the correct choice.
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
>As far as we are aware, only two languages in widespread use require
variables to be explicitly closed over: PHP and C++. All other major
languages capture implicitly, as is proposed here.
to be fair to c++, it supports [&] to capture everything, like
int a=1,b=2,c=3;[&]()->void{std::cout << a << b << c;}();
On Fri, 1 Jul 2022 at 16:05, Larry Garfield wrote:
> Greetings, Internalians.
>
> The vote for auto-capture closures is now open. It will run until 15 July.
>
> https://wiki.php.net/rfc/auto-capture-closure
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
[PHP-DEV] [RFC][Vote] Auto-capture closures
Greetings, Internalians. The vote for auto-capture closures is now open. It will run until 15 July. https://wiki.php.net/rfc/auto-capture-closure -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
