Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126881
Feedback-ID: id5114917:Fastmail
Message-ID: <4669e994-fe7f-4c3b-9920-ef6ac0118f1f@rwec.co.uk>
Date: Thu, 20 Mar 2025 21:41:25 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
To: internals@lists.php.net
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
 <CAMW7n8De15X4xDNOBULKeKkpeCeNo-tDWVWZ+Zer8vMa3U-vQg@mail.gmail.com>
 <d50b892b-9372-45c0-81ad-1ce818385b75@rwec.co.uk>
 <CAMW7n8C16d14earerxvCPe_kyym09GOa8mh4qwPz8AKVKQjHsw@mail.gmail.com>
 <e05cee9d-7901-4b18-b71c-24ad56266534@rwec.co.uk>
 <CAMW7n8AtLZOof54uJNFG+P4VVwbq65i79x-JDFKPJocDj-w91Q@mail.gmail.com>
 <DBDD7E90-DE94-4A9D-91F2-5CA9E712AE33@rwec.co.uk>
 <CAMW7n8DYBf73h2maPPcrPAGfEgdEdjeDoYrrD17fmxp9v_gx+g@mail.gmail.com>
 <6987D912-CE46-4145-A8CE-732CA590A522@rwec.co.uk>
 <CAMW7n8BJcTuTQj_AB4ha-RUF_AY5oKp1y0TaN-+CZOSLpmEoZw@mail.gmail.com>
 <2F013672-9937-4AB1-BC46-86F3D342BE6B@rwec.co.uk>
 <CAMW7n8CmaAFmUVgeJ+Xcxo52yS7O3KjU_LfRx8E6-KZqDxGVEg@mail.gmail.com>
 <743c84d4-28db-4f68-80e5-3cad2dac6e68@rwec.co.uk>
 <CAMW7n8DUZyoEMfYCV=P61hvN12DetYFee3E4S8O1gFfYu05okA@mail.gmail.com>
 <C8ACD74F-D046-4C08-B68D-65C078F2565E@rwec.co.uk>
 <CAMW7n8CmJcbjNw6avaexF1pGO=eJ8HP=OgC8amZPWjiFBF-3Fg@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMW7n8CmJcbjNw6avaexF1pGO=eJ8HP=OgC8amZPWjiFBF-3Fg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 20/03/2025 11:01, Edmond Dantes wrote:
 > >
 > > Specifically, what is the use case where syntax #2, "spawn 
function_call" is not good enough, leading us to add a special case into 
the grammar.
 > >
 > Additional parentheses around + parentheses after. That is, 
(closure)(). The goal is to get rid of this construct.


Again, that's the *how*, not the *why*. We only need to "get rid of" the 
parentheses if there's some reason to type them in the first place.


 > A safer approach would be to implement only syntax 2 and consider the 
alternative option only if user feedback suggests it's needed. Sounds 
like a solution without drawbacks...


This is pretty much where my mind is going - if we can't articulate an 
actual reason why "define an inline closure and pass it to spawn" is so 
common it requires special implementation, then let's keep it simple.


 > ```php
 > spawn fn() => [file_get_content(), file_get_content(), 
file_get_content()]
 > ```
 >
 > At this point, I haven't been able to come up with examples where 
such a closure would actually be convenient.
 > Maybe this use case will emerge later.


I was thinking of something like this maybe:

$contentFuture = spawn ( fn() => file_exists($filename) ? 
file_get_contents($filename) : '!! no such file !!' )();


Or even:

spawn ( fn() => do_something( fetch_something($input) ) )();

Which looks like it would be equivalent to this, but isn't:

spawn do_something( fetch_something($input) );

(It calls fetch_something() inside the coroutine, rather than outside it.)


If anything, this seems like a better candidate for a shorthand than the 
full closure syntax, because we already have the rules for automatic 
capture and automatic return available to reuse.

Maybe it could be as short as this:

spawn => do_something( fetch_something($input) ) );

 From longest to shortest:

spawn ( function() use($input) { do_something( fetch_something($input) 
); } )();
spawn function use($input) { do_something( fetch_something($input) ); };
spawn ( fn() => do_something( fetch_something($input) ) )();
spawn => do_something( fetch_something($input) ) );

Or, if we get Pipe syntax, it could end up like this:

spawn => $input |> fetch_something(...) |> do_something(...);


Again, though, this could easily be added later when a need becomes 
visible, as long as we don't do something weird now that closes the door 
on it.


I suggest we leave this sub-thread here; there's plenty of other things 
to discuss. :)


-- 
Rowan Tommins
[IMSoP]