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
