行程报告：夏季ISO C++标准会议（多伦多）的工作组-yiteyi-C++库

null

夏季2017届ISO C++标准会议于七月10-15日召开。多伦多大学 . 非常感谢谷歌、Codeplay和IBM，以及来自Mozilla、Collè通用电气莱昂内尔格罗克斯，佳士得数字系统公司和苹果公司帮助组织。当然，我们非常感谢滨水国际在中国大厦举办宴会 .

我们今年在多伦多举行了一次富有成效、相当和谐的进化工作组（EWG）会议。在五天三晚的会议上讨论了45项提案：周二晚上的概念会议和周四晚上与SG7（反思和元编程研究小组）的联席会议。我们大多数人也参加了星期一晚上的会议 P0684R0型 C++的稳定性、速度和部署计划。

C++标准委员会会议是一项非常艰巨的工作：每天早上和下午，在EWG这样的小工作组中花四小时的时间，在大多数晚上，花几个小时深入讨论一个主题。周六将有一个全体会议闭幕，大约120名来自世界各地的专家参加了会议。但这一切都很顺利，因为在会议之间有很多工作要做 21工作组主席，当然还有论文作者和所有与会者，他们（应该）在演讲前阅读了他们将要讨论的大部分论文。在会议之间还有更多的工作要做，以改进提案：很少有重大提案在第一次陈述时被接受。正如WG21的召集人herbsutter所说，“顺利从来不是偶然的。”如果你想让事情顺利进行，你必须做好准备。

网上有许多旅行报告，每个人都可以从网上得到经验丰富的参与者到第一次 . 这份报告故意狭隘。它集中在进化工作组，在那里我作为工作组的书记员度过了我的时间。这份报告意在总结EWG在多伦多的工作，而不是解释整个C++标准工作组（WG21）的进展情况。

所有论文都有链接。链接服务应该自动转发到论文的最新版本，而不一定是多伦多讨论的版本。如果您查看的论文有更大的修订号（例如，PxxxxR1而不是PxxxxR0），则应该包含多伦多讨论的反馈。

概念技术规范并入标准草案

多伦多会议最大的消息是我们合并了概念TS 进入 C++草案标准对于C++ 20，演示文稿是在一个马拉松式晚间会议上取消模板引导器语法和“自然语法”的。本提案的既定目标， P0696R0型，是删除概念语法中有争议的部分，以便我们能够成功地将TS合并到标准草案中。

支持自然语法（也称为“缩写”或“简洁”语法）的主要论点是，它支持泛型编程，特别是 Stepanov风格的泛型编程 . 重点是用法，而不是语言本身。简化语言的使用促进了良好的编程风格和范例。

经过多次讨论，该小组投票决定删除这两种语法，并指出我们可以在稍后添加自然语法。举的例子是，我们在引入lambda时没有包含通用lambda，以及 constexpr 在C++ 11中引入了它的能力，EWG致力于在未来的会议中恢复缩写语法，理想的是在C++ 20完成之前。

我们就概念问题进行了六次讨论。讨论按时间顺序排列。以后的讨论可以部分地推翻先前讨论的决定。

工作草案的项目编辑Richard Smith和Concepts TS的项目编辑Andrew Sutton发表了两篇论文，每一篇都得到了强有力的支持。
- P0717R0型：本提案简化了确定两个约束是否相等的规则。以前，实现必须逐个令牌比较等价性的概念。
- P0716R0型：在2017年2月的会议之前，我们有两种编写概念的方法：一种作为函数，一种作为变量。该方案统一了概念定义语法。具体来说，它删除了关键字 bool 以及变量声明语法的其他复杂性。
P0691R0型列出了TS概念的当前问题。我们只讨论了问题21：需要用括号括起来 requires 帮助解析的子句： requires(bool(T))) .
P0694R0型：本文伴随着bjarnestroustrup关于使用概念的函数声明的“自然”语法的演示。
P0696R0型：周二晚上的讨论涉及这项提案——见上文的摘要。
周三下午的最后一次讨论是向核心工作组（Core）澄清 auto 在模板中，变量类型的参数、参数声明或返回类型不应有效。讨论的目的是为了解决星期二晚上的决定中的一些松散的问题。

发送给PDT的模块技术规范

EWG的大新闻应该是我们在模块TS 如果不是概念偷了节目。来自Google和Microsoft的代表谈到了他们采用模块的经验，编译器实现者建议对TS的措辞进行澄清和修改。在闭幕式全体会议上，我们派出了小组成员进行意见和批准投票，称为PDTS。在C++ 20周期中，早期的PDT增加了在C++中包含时间的抛光C++模块的机会。

我们就模块进行了八次讨论：

P0629R0型：本文提出了一种语法， export module M; 区分接口和实现。目前，编译器知道是编译接口还是编译实现的唯一方法是命令行选项或文件后缀。我们批准了这个提议，并把GCC模块的实现者nathansidwell（Facebook）送到了Core。
P0584R0型：我们没有就模块接口分区能够跨多个文件拆分接口达成共识。很明显，有些开发人员想要分区，但EWG成员不清楚应该做什么更改。
Nathan Sidwell（Facebook）也提到了模块TS中一些模棱两可的措辞。模块TS的编辑Gabriel Dos Reis在模块TS问题列表中捕捉到了这些。

P0721R0型：关于使用声明导出的模糊性。我们认为措辞含糊不清，但在会议上没有达成行动计划。我们把这个留给内森和加布里埃尔最后决定。
P0714R0型：关于在命名空间范围内外导出具有相同名称的实体。

彭博社代表介绍 P0678R0型，列出了模块的三个业务需求集。我们同意所写的模块TS满足这些要求。

模块必须是可添加的，而不是侵入性的，这样库就可以通过头文件或模块向不同的使用者公开。
模块可以在更高的抽象级别上支持库接口。
模块不允许脆弱的传递包含。

来自Google的chandlercarruth介绍了他们修改构建系统以自动转换一些公共头文件作为Clang模块使用的经验，从而提高了构建吞吐量。
来自微软的gabrieldosreis介绍了他的公司在巨大的Windows代码库和构建系统中大规模使用模块的经验和期望。
P0713R0型：Daveed Vandevoorde，EDG编译器的实现者，建议我们在文件的顶部标记全局模块声明。这允许解析模块单元源文件的编译器在解析文件顶部时知道它是模块，而不必从生成系统、编译器开关或文件扩展名传递上下文。我们将在模块PDT发布后采用此更改。

协同程序技术规范（还有另外两个！）

如果仅仅将概念转移到标准中，将模块转移到PDT中还不够，那么更大的WG21小组也完成了我们对协同程序TS，网络TS，而rangests.EWG的部分目的是澄清关于协同程序TS（CH001和US013）的几个问题并不是应该阻止将协同程序TS合并到标准草案中的缺陷。看到了吗 P0664R0型更多细节。

C++ 20正在形成一个令人兴奋的版本！

其他晚间课程

除了晚间会议上的概念，我们还与SG7、反思和元编程研究组进行了晚间会议，并讨论了C++的稳定性、速度和部署计划。 P0684R0型 ).

星期四的SG7会议讨论了许多文件，包括 P0670R0型 , P0425R0型 , P0707R0型，和 P0712R0型 . P0327R2型由EWG在日间会议上直接处理。您可以在Herb Sutter的帖子中阅读更多关于元编程的文章：元类：生成C++的思考 .

星期一晚间会议上关于C++未来的一个话题是我们是否可以通过删除标准中不受欢迎的特征来真正地破坏代码。 P0619R1型几天后，在EWG中听到了许多可能被删除的不推荐的特性。在讨论了其中三个关于核心语言（相对于库更改）的问题之后，我们决定唯一可以删除的是 throw() ，这已被三个标准否决。

发送到Core的提案

在这次会议上，有四项提案被送交核心委员会。当一个提案被转发给Core时，意味着EWG已经批准了设计，并要求Core审查措辞将该提案包含在标准草案中。在这一点上，一个提议似乎已经完成了，但是实际上只完成了一半 . 从EWG的角度来看，这是旅程的终点，但要成为已发布标准的一部分还有很长的路要走。

下列提案已转交核心委员会：

P0683R0型：我们先前决定需要位字段默认成员初始化的语法。这个建议缩小了语法选择的范围。
P0641R0型：本文件涉及Core提出的第1331号问题。包装器类型出现了这个问题，其中构造函数的参数是对非- const 可能与默认副本冲突。
P0634R0型建议 typename 关键字必须是可选的，例如。， template<class T> struct D: T::B { // No `typename` required here
P0614R0型：这提出了一种新的基于范围的 for (init; decl : expr) 允许在 for 而不是要求初始化语句在 for 声明。

EWG批准了其他一些提案，但没有立即发送给Core。一些人被送到图书馆进化工作组（LEWG）从不同的角度进行更多的工作。其他人被批准去核心，但直到11月在阿尔伯克基的会议。请参阅下面的更多信息，以及一些被EWG拒绝的信息。

设计中的其他建议

WG21主要是一个设计小组，EWG的主要活动是讨论语言应该如何发展。我们接受、提出、考虑并拒绝了许多其他建议。下面是我们讨论过的所有其他内容的列表，大致分为几个主题。

功能测试宏

关于功能测试宏的未来，我们做了三次演示： P0697R0型 , P0723R0型，以及一个名为“被认为有害的特性测试宏”的演示文稿。经过大量的讨论，我们决定对现状做一个小小的改变：关于特性测试宏的文档SD-6将仍然是WG21编写的规范，但我们将计划让WG21正式批准它，作为一个集团全体会议的常设文档。

结构化绑定

P0609R0型：此建议允许属性，例如 [[maybe_unused]] 在结构化绑定的成员上。

记忆

P0132R0型探索内存受限环境中的非抛出容器。
P0639R0型：在过去的会议中，我们讨论过 constexpr_vector 和 constexpr 串。考虑的选项是在 constexpr 上下文或有 new 和 delete 在…工作 constexpr 上下文。这项建议得到了大力支持，将在今后的会议上再次提出。
P0722R0型提出另一种形式的 operator delete() 对于可变大小的类。讨论提出了许多问题，需要在提案提出之前加以回答。

参数推导、查找、类型检测、专门化

P0702R0型本文阐述了类模板参数推导的设计澄清。它向EWG提出了之前提出的想法。
P0389R0型：本文提出了措辞澄清，以帮助对函数模板的某些调用进行参数相关的查找。我们在讨论中意识到实际上我们可以去掉 template 这些电话中的关键字。一篇新论文即将发表。
P0672R0型：提供了一种方法来定义语法，以允许对代理和表达式模板进行类型检测。它还提出了一个 noeval() 禁用隐式计算，但仍允许自动类型推断。
P0665R0型允许在不同的命名空间中使用完全限定名专门化类模板。这有助于保持代码的局部性。

兰巴斯

P0624R0型：这提出了默认的可构造和可分配的无状态lambda，允许在当前的函数对象所在的位置使用它们。程序员或元程序员可以在线创建一段可以从类型系统中存储和检索的代码。
P0238R1型：此建议旨在使lambda对受约束的库更有用。它得到了强大的支持和鼓励，致力于一个简洁的lambda语法。

索引到位域和元组类型

P0573R1型：我们鼓励 bit_sizeof 和 bit_offset 操作员要等待反思研究小组的进展，才能启用这些操作员。
P0327R2型关注 std::product_type . 我们还没有一个语法来建议产品类型操作符来获得大小和第n个元素。希望这能回到EWG。

精确的断言和标记不可到达的代码

P0681R0型：Lisa Lippincott继续研究断言的精确语义。在本演示结束时，我们确定了三个我们希望看到进一步探讨的方案，两个与合同一起在EWG中，还有一个， std::unreachable ，在LEWG。
P0627R2型：一个 std::unreachable 该类型得到认可，并转发给LEWG作进一步讨论。
P0627R1型：此建议建议使用一个属性来标记无法访问的代码，类似于 __builtin_unreachable() 或 __assume(false) .

我们不赞成的建议

有些提议，无论多么合理和有见地，在目前看来都不太适合这门语言。有些提议如果通过，似乎会带来太多的复杂性。其他的只是一些不适合语言的好主意。EWG不鼓励就下列提案开展进一步的工作，除非对办法作出根本性的改变，使这些提案更受工作组的欢迎。

P0312R1型：本文建议使指向可调用成员的指针受益于泛型代码。该组织既没有强烈的支持，也没有强烈的反对，但面临着国家机构的强烈反对。因为没有国家机构的共识，标准草案是不可能被批准的，所以在我们能够向前推进之前，作者有责任努力达成共识。
P0671R0型：命名函数参数或“参数函数”是其他语言中的常见功能。他们已经多次提出C++的不同形式，但句法含义很难处理。
P0654R0型：添加 explicit 到 struct 要求初始化所有成员。这个建议很有意思，但由于编译器可以验证所有成员是否都已初始化，因此我们可能希望使用相反的方法来抑制编译器在 struct .
P0637R0型：允许的lambda按值捕获 *this 将其重新绑定到任意对象。在lambda中，捕获 *this 只能按名称捕获，不能按初始值设定项捕获。这个提议是针对init捕获的 *this .

最后

这是一个伟大的会议，一如既往，一大堆工作。想到一个由120人组成的小组可以会面并决定任何事情，真是令人惊讶，但我们在多伦多会议上取得了相当大的成就。我个人期待着我们在阿尔伯克基的会议在今年十一月，我们可以继续建立一个惊人的C++ 20版本！

和往常一样，感谢数百人谁提供反馈，并帮助我们改善C++经验在VisualStudio中。如果您对我们的团队有任何反馈或建议，请告知我们。我们可以通过以下评论和电子邮件联系到您( visualcpp@microsoft.com )你可以通过帮助>报告产品中的问题，或通过开发者社区 . 你也可以在Twitter上找到我们( @视觉 )还有Facebook( msftvisualcpp软件 ).

文章版权归作者所有，未经允许请勿转载。

THE END

C++