Re: PHP True Async RFC Stage 4
| From: | Rob Landers | 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