Re: PHP True Async RFC Stage 4

From: Date: Wed, 22 Oct 2025 08:53:46 +0000
Subject: Re: PHP True Async RFC Stage 4
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-128897@lists.php.net to get a copy of this message
On Wed, Oct 22, 2025, at 10:43, Rob Landers wrote: > On Wed, Oct 22, 2025, at 10:34, Edmond Dantes wrote: >> > A simpler solution might be to keep things as they are, but have the non-idempotent >> > constructs be generators of Awaitable instead of non-idempotent Awaitables >> So it’s the same as in C#? >> >> The problem with this situation is that so far I haven’t been able to >> find any cases proving that a non-Future object could cause serious >> failures in the code. >> >> At the same time, if a select case expression is introduced in the >> future, it would make more sense for select to work with an awaitable >> object rather than a Future. >> >> That’s why I’m not yet sure it’s worth abandoning the general behavior >> unless a convincing argument is found showing that it leads to real >> problems. >> >> -- Ed >> > > The example I gave is probably a good one? If I'm writing framework-y code, how do I > decide to await once, or in a loop? In other words, how do I detect whether an Awaitable is > idempotent or will give a different result every time? If I'm wrong, I could end up in an > infinite loop, or missing results. Further, how do I know whether the last value from an Awaitable > is the last value? I think if you could illustrate that in the RFC or change the semantics, > that'd be fine. > > — Rob Accidentally sent too early: but also, what if there are multiple awaiters for a non-idempotent Awaiter? How do we handle that? — Rob

« previous php.internals (#128897) next »