Stephan T Lavavej 最初的提议make_unique是N3588
它包括以下功能：
make_unique<T>(args...)
make_unique_default_init<T>()
make_unique<T[]>(n)
make_unique_default_init<T[]>(n)
make_unique_value_init<T[]>(n, args...)
make_unique_auto_size<T[]>(args...)
但是，最终提案N3656仅包括make_unique（两种形式）。我找不到关于该功能的其他形式的任何讨论。我阅读了布里斯托尔会议的记录，但他们甚至没有提及原始提案。
为什么这些额外的功能没有包含在最终草案中？
我阅读了布里斯托尔会议的记录，但他们甚至没有提及原始提案。
分钟是准确的。N3588（原始配方，没有标准版）没有在整个委员会讨论，只有 N3656（特脆，有标准版）在那里讨论。如果您没有参加过会议，这可能看起来很奇怪，但实际情况是工作组（Core、Evolution、Library、Library Evolution）和研究组（文件系统等）在一周内并行工作，最终进行民意调查（任何人都可以投票）以确定应该提交给全体委员会的内容。在第二天到最后一天，全体委员会（100 多人）开会，简要讨论正式动议，并进行民意调查（只有投票成员可以投票）。如果有人担心功能不够完善，或者其他功能会出现集成问题等。然后在这里讨论 - 但整个委员会不会关注提案的微观细节。基本上，如果某件事有足够的争议性足以保证这一点，它无论如何都不会在投票中幸存下来，因此它将被撤回对该会议的考虑。然后在最后一天，全体委员会再次开会，进行真正的投票（仅限投票成员）。一般来说，在实际投票期间应该不会有任何意外，因为前一天是试运行。
LWG 会议记录不公开，但我可以告诉你发生了什么。N3588 故意不包含标准语言——我在那里所做的是探索设计空间，找出我们应该模仿的新表达方式，并支持或反对各种事物。我正计划从 LWG 获得反馈，然后为下次会议（芝加哥）起草 Standardese，因为编写任何复杂的东西都需要我很多时间才能完全正确（这比实际实施它需要更多的时间，因为 Standardese 小心翼翼地跳舞围绕实施细节，如 SFINAE）。在提出提案时，我解释了我如何不是 default-init（我嘲笑为垃圾初始化）的忠实拥护者，但概述了无论如何可以做到这一点。我还解释说，自从编写提案（同时收到来自 MS 开发人员的反馈）以来，我已经了解了更多关于 array-init 案例的信息。有趣的是，核心语言为花括号初始化列表提供了顺序保证，因此 new X[3]{ f(), g(), h() } 从左到右调用这些函数。函数调用没有得到这些保证，这（在我看来）会像我最初的提议中那样尝试包装 array-init 致命伤。有一些巧妙的方法可以通过稍微不同的用户语法和更高的实现复杂性来实现排序保证，我向 LWG 解释了这一点。在这一点上，我真的很想放弃 array-init，而且我对 default-init 不冷不热（这很容易指定和实现，但我认为它本质上是不必要的）。LWG' 他们的反应是他们只想要最简单的形式——没有array-init，甚至没有default-init。听到这个我非常高兴，而且我能够在会议本身（大约凌晨 4 点）写下必要的标准语。这就是 N3656 的来源。LWG 又看了看它，通过一个小调整（将 make_unique<T[N]> 的返回类型从 void 更改为 unspecified，我在它“一成不变”之前就这样做了）准备将它带到全体委员会。
然后，正如您在会议记录中看到的那样，我们担心 make_unique 可能进展得太快了。N3588 准时在会前邮寄，但这是它第一次出现——几乎所有提案都需要不止一次会议才能从第一次出现到正式动议（我的第一个提案，透明的算子函子是一个更不寻常的例外，因为它出现并且在波特兰没有变化就被投票通过）。顺便说一句，这是一个完全有道理的担忧。最后，投票通过了——成员不必解释他们的投票，但我的感觉是，这是提案非常小，没有人对实际内容提出异议，以及可用的实现的结合。
现在我将不得不为 make_shared 重新考虑所有这些东西！