在20标准刚发布时，我曾读过几篇介绍20标准协程的文章，那时感觉标准里的协程难用，离开箱即用还很远，且当时编译器还没支持协程。
写本文时重读标准的协程方案，有了不同的看法，对于语言标准来说，20标准中的coroutine是一个基础设施，作为基础设施只需要提供足够的自由度就行。
那么废话少说，以下是c++20标准的协程详解。

why coroutine

本想在第一章系统介绍下协程这个概念，写写发现这话题太大，况且对于老码农来说也不需要我在这啰嗦（Go的goroutine、lua的coroutine）。如果你不知道协程，只需要知道协程是一个用户态的可挂起可恢复执行的函数即可。
本节聊聊为什么c++在要加入协程：

背景

c++一直以来使用c风格#include头文件方式引入依赖，而#include的方式存在诸多问题长期被程序猿吐槽，细数下来，这些问题包括不只限于：

include方式存在的问题

拖慢编译速度

这也是标准委员会引入module的主要原因，#include只是把头文件贴过来将代码段变成一个拥有完整上下文定义的整体，编译时就会出现引用的某个代码段在多个编译单元内重复编译然后链接时再合并的过程，重复编译自然会拖慢效率。

三年一度的C++标准文章这回在不到两年的时间点就开始了（请想象自嘲口吻），这次是一个持续更新形式，主要由于本就是利用业余时间写的，近两年家里又多了个小淘气，闲暇时间就越发少了，尽早更新完吧。这次看到中文维基百科上C++标准的条目内容有所缺失，所以同时还会持续更新这个页面维基百科 C++20，当然维基百科上不能像这篇文章里一样这么多废话。😂

新的语言特性

特性测试宏

或称功能特性测试，在c++标准中增加了预处理宏用以检测当前的c++功能支持情况，以往这些预处理都是根据编译器版本宏来控制，现在标准中增加了这些宏。
这些宏包含：

1. 属性检测宏__has_cpp_attribute，形式是宏函数内传递属性token：

写这篇的背景是当前很多shell都会有git prompt脚本，即对当前git仓库分支、改动情况的提示。
git分支命令的执行通常不会占用太多时间，但是改动情况的命令如git status或者简短版本的git status --porcelain则不然，特别是当仓库项目很大时，当你有以下我的使用场景时则更为糟糕。目前我个人的开发环境是windows+wsl，习惯上我会在win上通过git for windows的版本clone代码，然后在wsl里访问编辑，在这种场景下你会发现在wsl中的git status命令执行时间更长（这里我没深究其原因），特别是当你每敲一行命令shell都会去执行git status就更加恼人。
以下为个人的折腾记录，“可能”会不断更新不同shell的情况：

总体结构

variant

首先是variant的结构，variant的模板声明长这样：

1
2
3
4
5
6
7
8
9
10
11
12

template<typename... _Types>
  class variant
  : private __detail::__variant::_Variant_base<_Types...>,
    private _Enable_default_constructor<
      __detail::__variant::_Traits<_Types...>::_S_default_ctor,
        variant<_Types...>>,
    private _Enable_copy_move<
      __detail::__variant::_Traits<_Types...>::_S_copy_ctor,
      __detail::__variant::_Traits<_Types...>::_S_copy_assign,
      __detail::__variant::_Traits<_Types...>::_S_move_ctor,
      __detail::__variant::_Traits<_Types...>::_S_move_assign,
      variant<_Types...>>

_Enable_copy_move在上一篇optional解析中解释了，这里不同之处在于要考察variant的模板参数包内多个类型的可复制性、可移动性，如果其中某个类型不可复制或不可移动，那么variant亦不可复制或不可移动。
_Enable_default_constructor为用于生成默认构造的helper模板，代码长这样：