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.