Share via

出差报告：关于在多伦多夏季ISO C++ 标准会议的进展

  • 09/05/2017

[ 原文发表地址 ] Trip report: Evolution Working Group at the Summer ISO C++ standards meeting (Toronto)

[ 原文作者 ] Andrew Pardoe

[ 原文发表时间 ] 2017/7/28

2017夏季ISO C++ 标准会议在7月10号到15号在多伦多大学如期举行。非常感谢Google, Codeplay 和IBM对本次会议的赞助，以及来自Mozilla，CollègeLionel-Groulx，Christie Digital Systems和Apple的帮助与组织。 当然，我们也非常感谢海滨国际在加拿大国家电视塔举办宴会。

今年在多伦多，我们有一个很有成效且相当和谐的发展工作组（EWG）。在五天三夜的会议上我们讨论了45个提案，其中周二晚上的Concepts和关于SG7的会议都是关于反思和编程研究小组的联合会议。我们大多数的人也参加了周一晚上关于P684R0, C++稳定性，速度和部署计划的会议。

C++标准委员会非常辛苦的工作，每天上午下午四小时的小型工作组讨论（如EWG）而且还要在晚上深入讨论一个课题几个小时。周六全球有约120位来自世界各地的专家参加此次闭幕会议。因为WG21成员在会议举行期间做了很多工作，所以一切都很顺利的进行。小组主席，论文作者和所有的参会人员阅读了大量的论文，并且在演讲之前做了很多讨论。在这里会议里我们做了大量的工作来改进提案：在第一次的演讲中几乎没有重要的提案被接受，正如WG21召集者Herb Sutter说”顺利的事不会偶然发生”。如果你希望事情顺利进行，那么你必须提前做好准备。

这里有每个人从第一次到有经验的参与者的许多在线出差报告。这次报告非常的集中，主要专注于EWG，在那里我是工作组的抄写员。主要把时间花在缮写上。这份报告旨在概述EWG在多伦多的工作情况，而不是对C++标准工作组进展的记录。

为所有的论文提供链接。连接服务器自动转到论文的最新版本，而不一定是当时在多伦多讨论的版本，如果你查看的论文版本较高的话（如：PxxxxR1 而不是 PxxxxR0），那应该是收纳了来自多伦多讨论的反馈之后的版本。

Concepts技术规范合并到草案标准

多伦多会议上最大的消息就是我们把Concepts TS 合并到了C++20草案标准中。这次演讲用一个马拉松式的环节把会议推向了高潮，移除了模板导入语法和“自然语法”。此提案P0696R0阐述的目标移除Concepts语法中有争议的部分，以便我们可以将TS成功合并到标准草案中。

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

经过多番讨论，小组投票删除了这两个语法，需要注意的是我们将在以后添加自然语法。提出的例子就是时候事实上我们没有包含泛型的Lambdas当我们引入Lambdas，并且引入C++11的constexpr的重大扩展。EWG致力于在未来的会议提案中提供缩写语法，理想情况下C++20完成之前。

我们就Concepts这个话题讨论了六次，这些讨论按时间顺序列出，稍后的讨论可以部分的覆盖先前讨论的决定。

  • Richard Smith（工作草案项目编辑） 和Andrew Sutton（Concepts TS 的项目编辑）提交了两篇论文，每篇文章都得到了强有力的支持。
    • P0717R0：该提案简化了两个约束是否相等的规则。在以前，实现必须逐个比较相等的Concepts。
    • P0716R0：在2017年2月的会议之前，我们有两种Concepts的写法：一种是函数，一种是变量，该提案统一了Concepts的语法定义。具体来说，它删除了关键字bool 和其它复杂的变量声明语法。
    • P0691R0：列出了Concepts TS 当前的问题。我们仅仅扑捉到了问题21：需要括号内的requires 语句来帮助解析requires (bool(T())).
    • P0694R0：本文是Bjarne Stroustrup的一篇演示文稿，介绍了使用concepts的函数声明的“自然”语法。
    • P0696R0：星期二晚上的讨论涉及到了这个提议----见上文摘要
    • 星期三下午最后的一次讨论是向核心工作组（Core）澄清一个变量或者一个参数声明或者一个返回类型的模板参数是auto的话就是无效的。这次讨论是从星期二的决议中去除一些琐碎的问题。

推送PDTS的Modules技术规范

EWG的最大新闻就是我们在Modules TS上取得的进步如果Concepts还没有偷偷展示的话。谷歌和微软的代表谈到关于他们采用Modules和编译器实现的经验，提出了对TS措辞的澄清和修改。在闭幕会议上，我们发起Modules TS的讨论和批准投票，我们叫做PDTS。C++20的初期会增加及时抛光C++ Modules 的机会。

8个Modules的讨论：

  • P0629R0：本文提出了一种将接口与实现分离开来的语法，export module M；目前，编译器识别编译接口和实现的唯一方法是命令行选项或文件后缀。我们提出了这个建议，并将GCC的Modules的实施者Nathan Sidwell（Facebook）发送给了Core.
  • P0584R0：我们没有达成对Module接口分区的共识----能够跨多个文件的分离式接口。很明显的是一部分开发人员想要分区，但是EWG成员不清楚应该做什么样的改变。
  • Nathan Sidwell（Facebook）还在Module TS 中提出了一些有分歧的措辞。Module TS 的编辑Gabriel Dos Reis在Modules TS 问题列表中提到了这些。
    • P0721R0：关于使用export声明的争议，我们认为这个词是含糊不清的，但是没有在会议上没有个明确的计划。我们把这个让 Nathan 和 Gabriel去确定个提案。
    • P0714R0：关于在命名空间输出相同名称的实体。
  • 彭博社的代表介绍了P0678R0， 列出了Modules的三个业务要求。我们书面同意满足这些需求。
    • Modules必须是可加的，而不是侵入性的。比如一个库文件或者Modules能够提供给不同的消费者。
    • Modules可以支持库文件接口在一个更高层次的抽象下。
    • Modules不允许脆弱的传递包。
  • 来自Google的Chandler Carruth介绍了通过修改构建系统经验来提高构建吞吐量的效率，为了将一些常见的头文件自动转换为Clang模块。
  • 来自微软的Gabriel Dos Reis介绍了他公司的经验和关于在windows代码库和构建系统中使用modules的期望。
  • P0713R0：EDG编译器的实现者Daveed Vandevoorde建议我们在文件的顶部标记全局的Moudle声明。这样就允许编译器解析module模块源文件，当解析到文件顶部的时候去识别他是一个module，不需要通过生成系统，编译器开关，或者文件扩展名传递上下文。发布Moudle PDTS之后，我们就采用这样的更改。

协程（ Coroutines ）技术规范（两个以上）

如果将Concepts移动到C++标准草案中，将Modules移动到PDTS还不够的话，那么更多的是WG21组织也完成了对Coroutines TS，Networking TS和Ranges TS的审阅。EWG说明了关于协程TS的两个问题（CH001和US013）不是阻止将Coroutines TS合并到标准草案缺陷。详细信息，请参阅P0664R0.

C++20正在形成一个令人激动的版本!

其他晚会

除了关于Concepts的晚会之外，我们还参与了SG7晚会，研究了C++稳定性，速度和部署计划(P0684R0).

周四的第七次会议讨论了很多论文，其中包括P0670R0，P0425R0，P0707R0， 和 P0712R0。P0327R2由EWG在白天的会议中直接处理的。您可以在Herb Sutter的帖子里查看更多关于元编程的论文，元类：对生成C++的思考。

星期一晚上是讨论C++未来的话题，关于我们是否可以通过从标准中移除不推荐使用的功能来实际的破解代码。P0619R1，在EWG听到几天之后，强调了可能被删除的许多不赞成的功能。 在讨论了关于三个核心语言（而不是库更改）之后，我们决定了唯一可以删除的是throw（），它已经在三个标准被淘汰了。

提案提交到Core

本次会议期间向Core提交了四项提案。当提案转交给Core时，这就意味着EWG已经批准了设计，并要求Core审查措辞将此提案纳入标准草案。就这一点来看，可能会完成一个提案，但实际上只完成了一半。从EWG的角度来看，这是出差的结束，但是成为可以公布的标准的一部分还有很长的路要走。

下边的提案转交给了Core：

  • P0683R0：我们以前决定我们需要一个字段默认成员初始化的字段。这个建议减少了语法的选择。
  • P0641R0：本文涉及Core的问题1331。该问题出现封装类型中，其中具有参数的构造函数是对非const的引用，可能与默认拷贝发生冲突。
  • P0634R0：此提案建议typename关键字是可选的。比如：template<class T> struct D: T::B{//没有用到typename}
  • P0614R0：提出了一个新的基于范围的初始化，声明，表达式。并且允许for语句本身的初始化语句。而不是要求初始化语句在for语句之前。

其他的一些提案已被EWG批准，但不立即发送到Core。有些则从不同的角度提交给标准库发展工作组（LEWG），从而进行更多的工作。其他人被批准去Core，但是得等到11月的阿尔伯克基会议。有关更多的信息，以及被EWG拒绝的信息，请看下文。

其它设计提案

WG21是主要的设计团队，EWG的主要任务是讨论语言应该如何演变。我们包容过，提升过，考虑过和拒绝过许多其它的建议。以下就是我们讨论过的一些列表，这些列表中排列了几个常规的主题。

宏测试

我们对未来宏的功能测试进行了三次演示: P0697R0， P0723R0和被叫做“宏功能测试且考虑有害”的演示。经过多次辩论，我们决定从现状出发做出小小的改变:有关宏功能测试的文件SD-6将仍然是WG21编写的规范，但是我们将计划在全体会议上将其作为常设文件添加到WG21.

结构化绑定 P0609R0：该提案允许在结构化绑定的成员上使用[[maybe_unused]]等属性。

内存

  • P0132R0：探索内存受限环境的Non-throwing容器。
  • P0639R0：在过去的会议上,我们讨论过constexpr_vector 和constexpr 字符串。考虑的点是constexpr代码的分配器和包含new和delete的constexpr代码。这个提案得到了很大的支持，将会在以后的会议上重新出现。
  • P0722R0：为可变大小的类提供了operator delete()的另一种形式，讨论开辟了很多问题，它们需要在提案向前推进之前被解决。

参数推倒，查找，类型检查，特例化

  • P0702R0：本文讨论了类模板参数推到的设计说明。它将以前的想法提交给了EWG。
  • P0389R0：本文提出了用语的说明，以帮助和参数相关的查找功能模板的一些调用。我们在讨论中意识到我们移除这些模板调用中的关键字事实。一份新文件即将发布。
  • P0672R0：提供给语法一个方法，以允许委托和模板表达式的类型检测。还提出了用noeval()来禁用隐式赋值，但是依旧允许自动类型推倒。
  • P0665R0：允许使用特例化模板存在于不同的命名空间使用全局限定名称。这有助于保持代码的局部性。

Lambda表达式

  • P0624R0：提供了默认可构造的和可分配的无状态的lambda表达式，允许它们在有函数对象的地方被使用。程序员或者元程序员可以在线创建一个来自类型体系可存储和检索的代码。
  • P0238R1：该提案旨在让lambda表达式在受限的库中更有用。这得到了很大的支持，并鼓励受用更简单的lambda语法。

索引到位和元组类型

  • P0573R1：我们期待bit_sizeof和bit_offset运算符，并且等待Reflection研究组取得的进展，使这些运算符成为可能。
  • P0327R2：涉及std::product_type。我们还没有提供语法支持该运算符来获取大小和第n个元素。期待EWG的反馈。

精确的断言和标记不可访问的代码

  • P0681R0：Lisa Lippincott不断地研究断言的精确语法。在本次演示文稿的结尾，我们确定了我们希望进一步探索的三个建议。
  • P0627R2：std::unreachable类型已经批准病准发个哦了LEWG进行深入的讨论。
  • P0627R1：该提案建议用一个属性来标记不可访问的代码，和__builtin_unreachable() 或者 __assume(false)相似。

不鼓励的提案

一些提案，无论他们有多么的有道理和洞察力，但在当前的语言时期都不被看作是好的建议。似乎有些提案在采用时会引入太多的复杂性。其他的看起来都不适合语言。EWG不鼓励对以下的提案进行更深入的工作，除非对方案进行了根本性的改变。使其更符合大众。

  • P0312R1：本文提出了提供指向可通用代码的成员指针。组织既没有反对也没有支持，但是需要面临国家的反对派。由于在没有国家架构共识的情况下，是不能批准草案的，因此作者必须努力达成这一共识才能推进。
  • P0671R0：命名函数参数，或者“带参函数”是其他语言的常见功能。他们已经反复提出了C++的不同形式，但是语法的含义很难解决。
  • P0654R0：在结构体添加explicit，以便初始化所有成员，这个提议很有趣，但是由于编译器可以验证所有成员是否能被初始化，我们希望使用相反的方法来抑制编译器对结构体的验证。
  • P0637R0：允许lambda通过*this捕获值将其重新绑定到任意对象。在lambda中捕获*this只能通过名字捕获，而不是通过初始器捕获。这个提议是关于初始捕获*this。

结语

这是一次伟大的会议，一如既往的工作量很大。令人惊讶的是总共120人可以满足和决定任何事情，但我们确实在多伦多会议上完成了很多事情。我个人期待着我们将在11月在阿尔伯壳基举行的回忆，我们可以急需建立一个惊人的C++20版本。

和往常一样，感谢如此多的人给的反馈，并帮助我们改进VS中的C++体验。如果您对我们的团队有任何的问题或者建议，请让我们知道。我们可以通过电子邮件（visualcpp@microsoft.com）和在本文下评论，也可以通过帮助->报告产品问题。或者去开发社区反馈。你也可以找到我们的Twitter（@VisualC）和Facebook（msftvisualcpp）进行反馈。