Consider storing just the context within a future

[kammce]

Currently, future holds a variant of a handle or its value of T. This works, but it means that future is not trivially movable. It has to update the promise to where it exists. This isn't an issue, but I do have concerns that this placement adds complexity to the coroutine operations which may reduce performance. I get the feeling each time I look at:

  constexpr void resume() const
  {
    handle().promise().get_context().active_handle().resume();
  }

With the context kept within the future we'd get:

  constexpr void resume() const
  {
    m_context->active_handle().resume();
  }

With the later being potentially, fully inline-able. Where as handle() must access std::get<> which can throw meaning it has a check. Promise() and the rest may be inline-able.

We would hold the result value within the promise as is usually the case.

[kammce]

In order for this to work, we will need to have a sort of no-op context, because if a future is destroyed, we have a promise that has the ability to modify the future that it is bound to, but we need to set its pointer to something. Just like how no-op coroutine allows us to point to an object that can be resumed and that resumption does nothing, we can do the same thing within no-op context. We can also utilize strong pointers, capability to point to to static objects without allocating or doing any ref counting. With that, we can make a no-op scheduler that basically does nothing for its schedule function. And if its allocate function is ever called, it should call terminate. The idea is that the no-op scheduler should never be accessible. Specifically, it should never have its allocate function ever utilized. It shouldn't be accessible and there should be no way to create it or access it and it's only around to allow futures to be set to something that can be resumed but never actually used.