VC++17及以后TS协程：为何协程类型必须可移动构造？

嘿，这个问题我之前折腾VC协程的时候也踩过坑，其实根源在于**C协程TS的底层机制**和VC++编译器的严格检查规则，哪怕你觉得构造函数永远不会被调用，编译器也有它的考量：

首先，你的resumable_thing作为协程的返回类型，VC++在编译协程代码时，会自动生成一堆和协程状态管理相关的隐含代码。这些代码里，编译器会预设一些可能的代码路径——比如协程挂起、恢复时的临时对象转移逻辑，哪怕你的实际业务逻辑根本走不到这些路径，编译器在语法检查阶段就会要求这个类型必须具备合法的拷贝或移动语义。它没办法提前预判你后续会不会用到这些语义，所以干脆先把规则卡严。

另外，你参考的McNellis 2016年的协程示例是早期实验性实现，那时候的协程规范还没那么完善，而VC++17+的协程支持已经更贴近后来的标准草案，对返回类型的要求自然更严格了，这也是为什么老示例放到新编译器里会遇到这种“额外要求”。

举个直观的例子，编译器生成的隐含代码里可能会有类似这样的逻辑（只是示意）：

// 编译器自动生成的协程内部代码
resumable_thing temp = some_internal_state; // 这里会触发移动/拷贝构造的检查

解决起来也简单：

• 如果你不需要拷贝功能，可以直接把拷贝构造函数删掉，然后默认移动构造：

  resumable_thing(const resumable_thing&) = delete;
  resumable_thing(resumable_thing&&) = default;
  

• 或者直接默认移动构造和移动赋值运算符，让编译器帮你生成合法的移动语义，就能顺利通过编译了。

说白了，这不是你的代码逻辑有问题，而是VC++的协程实现要求返回类型必须满足可移动（或可拷贝）的约束——编译器要确保这个类型具备应对所有潜在协程执行路径的能力，哪怕这些路径在实际运行中不会被触发。

内容的提问来源于stack exchange，提问作者Jive Dadson