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.
