前几天，国际标准化委员会C ++在美国城市科纳举行了会议。 这不仅是一次会议，而且还冻结了功能！ 没有严肃的新想法再也不会渗入标准，仅需召开几次会议就可以添加预先批准的内容，纠正缺陷并消除麻烦。
如果应该在C ++ 20中使用Modules和Corutins，是否会有一个用于格式化输出的快速库，是否可以使用日历，是否可以添加
std :: stacktrace ，编译器是否会在某些情况下开始调用
std :: self本身 ，是否会接受
std :: flat_map ？ 所有这些以及更多等待您的削减。
协程TS
围绕协程展开了最激烈的辩论。 委员会必须考虑三种不同的协程方法，并决定是接受现有的协程TS作为标准，还是采用不同的方法。
选择并不容易，每种方法都有其缺点和优点：
- N4775 ：
- +对于协程应在头文件中描述的事实没有任何限制
- -没有严格保证不会有动态分配
- ±不是最简单的接口（ P1477R0修复了此问题）
- -丑陋的关键字co_await和co_yield （ WP21的句子P1485R0修复了此问题）
- + 3年实践
- P1063R2 ：
- +没有动态分配
- -协程必须在头文件中描述，否则您需要使用类型擦除来欺骗自己
- -更可怕的键运算符[<-]和[->]
- -没有可用的原型
- -不是创建异步事物的最简单接口
- P1430R0 ：
- +没有动态分配
- -协程必须在头文件中描述，否则您需要狡猾地进行类型擦除
- +没有可怕的关键字，一切都很顺利
- + Corutin用户看不到可怕的协程内部（甚至看不到co_await类似物，所有东西都开箱即用）
- -第一个提案从未讨论过，需要大量改进
- -无法在当前技术上实施（需要对动态尺寸结构的支持），需要巨额人工成本才能实施
- ±有点像回调面条
经过大量辩论，协程在C ++ 20中被采用，就像在协程TS中一样（带有
co_ *前缀和旧的定制点）。
模组
关于模块的讨论受到一份有关性能评估的有趣文档的影响：
P1441R0 。 可以用不同的方式来解释结果：从“现有的组装系统和模块的实施还没有充分优化”到“随着项目的复杂性增加，模块无法很好地扩展”。
除本文件外，委员会还讨论了对当前模块的一些小改动。 结果，经过15年的讨论，原型设计和实现试验，该模块在C ++ 20中被采用。
格式
大家好消息！ 如果您在Library子组中没有发现致命的缺陷，那么在C ++ 20中，可以安全快速地格式化字符串。 与
std :: ios ，
std :: locale和90年代的其他恐怖告别！ Python现在具有类似的语法，可以在C ++中
立即使用格式进行格式化：
P0645R5 。
此外，接受了整合新格式和日历时间
P1361R0的建议。 如果一切按计划进行，那么日期可以以人为方式显示！
网络，执行器和属性
执行程序是开箱即用地支持C ++网络的重要基础。 执行者需要属性-能够修改数据类型，这取决于在编译阶段传递的参数，而无需更改类型的概念。
属性在
P1393R0中描述。 尽管包含在标准中的文字只有几页，但该提案引起了热烈的讨论。 该提议使您可以进行几乎万能的自定义点，使用“属性”更改任何功能的行为。
结果，决定仅在C ++ 23中以该语言包含“属性”，因此，在C ++ 20中不会出现“执行者和网络”。
其他
C ++ 20草案已进行了以下更改：
- 现在可以使用P0960括号来初始化没有构造函数（聚合）的结构。 实际上，这意味着现在std :: make_shared ， std :: make_unique ， std :: * :: emplace *可以在聚合时正常工作而不会编译错误
- 增加了线性插补P0811的 Lerp功能
- 增加了对P1001标准库算法进行矢量化的功能
- 现在， std :: span方法返回无符号类型（类似于整个标准库）+添加了std :: ssize函数以将容器的大小作为带符号的数字P1227
- 无序容器学习了如何使用预先计算的P0920哈希查找值
库和核心子组中的许多其他事项尚待最终审查，以包括在C ++ 20中：
RG21的优点
在第一天，Core小组就接受了深受欢迎的Yandex.Taxi对Stacktrace
P0881R3的建议。 在LEWG子组中进一步讨论了设计评论，并在Core中再次进行了设计。 结果，整周进行了更正并进行了讨论。 该建议尚未包括在标准草案中，但应该包含在C ++ 20中（如果他们突然发现一些致命的缺陷）。
在讨论我们的
P1485R0引入协程关键字的思想之前，还没有得出结论。
同样在SG1，并发讨论了并发无序映射
P0652R2的思想 。 我们被要求仔细检查所提出的API是否避免了读者争用。 他们还说要调查并发的无序容器，这些容器不具有擦除功能，并且不能保护容器的价值免遭竞争性修改。
ZaMaZaN4iK提出的针对标准库
P1406R0各种类的std :: hash专门化的提议
被决定严格削减。 委员会建议仅对用户分配器中的
std :: pair ，
std :: tuple ，
std :: array和
std :: basic_string保留专长。
在数字子集中，SG6讨论了用于交互各种新的数字
P0880R2的机制 。 该提议使您可以专门化两个模板，获得所有新类型的完整数学运算和比较集。 在讨论之后，他们决定尝试扩展该机制，以便不仅可以将其用于标准库的需求，而且用户也可以将这些运算符用于其类型。
我们还讨论了一些次要建议，包括功能测试宏
P1424R0以及将其添加到标准中的策略。
我们很快讨论了允许编译器删除
R0889R1不必要副本的
想法 。 我们被告知要继续朝这个方向努力，并举一些不应与新规则相抵触的例子。
代替总数
C ++ 20与C ++ 17的差异将与C ++ 11与C ++ 03的差异一样大。 大量的新技术和新范例：概念，合同，范围，模块，协程，constexpr容器和constexpr动态多态性，“生物体”等。
很快，
我们21工作组将发布有关C ++ 20标准草案的评论。 因此，如果您有任何痛苦或不同意任何创新，
请 在此页面上留下您的想法。
国际委员会的下一次会议将在夏季举行，届时可以开始考虑C ++ 23的创新。 如果您想用C ++进行更改或提出您的想法，您可以随时在
https://stdcpp.ru/上写信，WP21的人员将在其中帮助您向委员会传达您的愿望。
您想和我们聊天吗？
RG21的公开会议即将举行，
敬请关注events.yandex.ru上的公告 。 也可以在4月在莫斯科举行的
C ++俄罗斯会议上寻找我们。