Re: PHP True Async RFC Stage 4
| From: | Rob Landers | Date: | Wed, 22 Oct 2025 08:43:08 +0000 |
| Subject: | Re: PHP True Async RFC Stage 4 | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-128896@lists.php.net to get a copy of this message | ||
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