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
larry@garfieldtech.com
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;}();
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
larry@garfieldtech.com--
To unsubscribe, visit: https://www.php.net/unsub.php
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
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
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
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
Greetings, Internalians.
The vote for auto-capture closures is now open. It will run until 15 July.
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]
Hi there,
Greetings, Internalians.
The vote for auto-capture closures is now open. It will run until 15 July.
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
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).
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
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
larry@garfieldtech.com--
To unsubscribe, visit: https://www.php.net/unsub.php
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 theZend/Optimizer/, andzend_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.cnow depends onOptimizer/,
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,
Important to note how
Zend/zend_compile.cnow depends onOptimizer/,
which is a potential design issue.The Optimizer was moved to
Zend/Optimizerearlier 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" 😬
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 ?
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.
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.