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
