给定以下协程格式：
auto myhelper = [&]() -> mytask<int> {
co_await some_event;
co_return 5;
}();
以下真的是确保您不会重新分配的唯一方法吗？
auto myhelper = [&]() -> mytask<int> {
while (true) {
co_await some_event;
co_yield 5;
}
}();
因为我以这种方式构建我所有的协程，甚至无法找出一个像样的宏或函数手段来隐藏那个繁琐的循环，也不是一般的样板(即 {} 后的括号(。
我知道每promise_type自定义分配器，但认为开销太高(因为大小可能会有所不同，仍然需要检查免费列表，仍然有效地重新分配等(。
基于co_await的协程机制是围绕一个非常具体的使用场景设计的：您调用异步操作并挂起当前函数，并在异步操作生成值时计划其恢复。这是该功能背后的核心用例。即使是基于生成器的场景也只是这种形式的退化形式，其中没有异步操作，而 future/promise 机制反而赋予调用方恢复协程的能力。
您在此处执行的操作并非不正确，因为协程机制允许您通过单个协程未来执行这种重复执行某些异步操作。如果你觉得这是处理你想要完成的特定任务的最有效方法，你可以自由使用这种方法。
但是，"回收"协程句柄根本不是系统的真正用途。句柄最终终止。它们已创建，存在一段时间，等待某些操作，计划其恢复，然后完成。这就是范式。
因此，针对您的问题(避免分配内存(的设计解决方案是提供的基于 promise 的分配机制。你觉得这还不够好，因此，你被迫使用不那么美味，语法上更丑陋的机制。当您的需求与设计提供的需求不匹配时，通常会发生这种情况。
这可能只是您的需求与co_await式挂起协程不匹配的情况。也许真正的光纤对您的代码更有用。