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 a
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 de
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 dire
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
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:/
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
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-cla
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,
>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 Ju
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 v
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 ru
>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 <<
12 matches
Mail list logo
