Re: PHP True Async RFC Stage 4

On Wed, Oct 22, 2025, at 06:32, Edmond Dantes wrote: > Hi > > > I don’t think it’s a “rule” per se and why I suggested breaking it up into two > > different kinds of Awaitables. > > Invariants make code easier to reason about and work with. The more invariants you have, > > the easier it is to form, maintain, and refactor. > > So that is the rule: **invariants make code easier to understand**. > A more general principle is stated as follows: reducing complexity. > > I think this point needs some thought. > If the await operation is allowed only for Future, it will make the > code more consistent which is a good thing. > > Then it will be necessary to add a FutureInterface, and Awaitable > should be hidden from the UserLand namespace. 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. This would basically mean just changing some text in the RFC and some implementations that aren't documented in the RFC (as far as I can tell). — Rob