[wahern]

But without relocatable stacks you're incurring a large, fixed cost per coroutine.

Of course, with stackful coroutines you'll have a lot less coroutine objects. But the real issue is that you have to decide ahead of time how large you want to make the stack. Too large and you waste memory, too small and you'll blow the stack. In the context of individual projects the programmer can usually make the call without much trouble. But removing that kind of burden from the programmer is usually the primary reason you add such abstractions to the language standard. And it's why the typical execution stack is so huge (1+ megabytes) on most non-embedded systems (and even many embedded, network-facing systems).

[gpderetta]

boost.coroutine can be optionally used with segmented stacks. Copyable stacks are a problem in C++ as objects can have custom copy semantics.

Anyway, large stacks (assuming you want at least 1 page per coroutine) do not waste memory, they only waste address space which is plentiful. If you want slim coroutines, there are the shallow generator style coroutines of the other proposal.

There is some hope that we will have the best of both worlds, stackful coruoutine semantics plus annotations to opt in to the stackless coroutines optimization.

[wahern]

  There is some hope that we will have the best of both
  worlds, stackful coruoutine semantics plus annotations to
  opt in to the stackless coroutines optimization.

That would be pretty amazing. Are there proposals or committee discussions you could link to? If C++ got stackful coroutines I might finally make the switch from C.

[medi11]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p053...

call/cc is the basic mechanism - useful to implement stackful coroutines and fibers (cooperative multi-tasking)