make_unique数组，原始提案vs. final [英] make_unique arrays, original proposal vs. final
问题描述
Stephan T Lavavej对 make_unique 的初步建议是 N3588
它包含以下功能：
make_unique< T& （args ...）
make_unique_default_init< T>（）
make_unique< T []>（n）
make_unique_default_init< T [ $ b make_unique_value_init< T []>（n，args ...）
make_unique_auto_size< T []>（args ...）
但是，最终的propsal N3656 仅包含 make_unique （两个表单）。我无法找到任何关于其他形式的功能的讨论。我阅读了布里斯托尔会议的记录，但他们
为什么这些额外的函数不包括在最终草案中？ >解决方案
我读了布里斯托尔会议的会议记录，但他们甚至没有参考原始提案。
分钟数是准确的。 N3588（原始食谱，没有标准）没有在完整的委员会讨论，只有N3656（额外脆，与标准）在那里讨论。如果你没有去参加会议，这可能看起来很奇怪，但是会发生什么是工作组（核心，进化，图书馆，图书馆进化）和研究组（文件系统等）在一周内并行工作，最终进行草案投票（任何人都可以投票），以确定应该提交给完整的委员会。在第二天到最后一天，全体委员会（100多人）开会，在那里简要讨论正式动议，并进行草案投票（只有投票成员可以投票）。如果任何人担心特征没有被烘焙得足够，或者与其他特征等存在集成问题，那么这里将讨论这一点 - 但是整个委员会不会审视提案的微观细节。基本上如果有争议足以保证，它将不会生存的投票反对，所以它会被撤销对该会议的考虑。然后在最后一天，全体委员会再次开会，并进行真正的投票（只有投票成员）。一般来说，在实际投票中不应有任何惊喜，因为前一天是一个测试。
LWG会议纪要不公开发布，但我可以告诉你发生了什么。 N3588故意不包含标准 - 我在那里做的是探索设计空间，找出什么新的表达我们应该模仿，争论或反对各种事情。我计划收到LWG的反馈，然后为下一次会议（芝加哥）起草Standardese草稿，因为撰写任何复杂内容需要我花很多时间才能完全正确（比起实际执行它需要更多的时间，因为Standardese仔细跳舞围绕实施细节如SFINAE）。在介绍这个提议的时候，我解释了我是不是default-init（我把它称为garbage-init）的一个好粉丝，但是已经概述了它怎么做。我还解释说，自从编写提案（同时接收来自MS开发人员的反馈）以来，我已经学习了更多关于array-init的情况。有趣的是，Core语言为braced-init-lists提供了排序保证，所以新的X [3] {f（），g（），h（）}从左到右调用这些函数。函数调用没有得到那些保证，这在我看来，真的伤害了尝试包装array-init像我的原始提案。有一些聪明的方法来实现排序保证与稍微不同的用户语法和甚至更多的实现复杂性，我向LWG解释。在这一点上，我真的想删除array-init，我对默认init（这是很容易指定和实现，但我认为它本质上是不必要的）温暖。 LWG的反应是他们想要最简单的形式 - 没有array-init，甚至没有default-init。我非常高兴地听到这个，我能够在会议上写上必要的标准版（如上午4点）。这就是N3656来自的地方。 LWG再次查看它，并且有一个小小的调整（将make_unique< T [N]>的返回类型从void更改为unspecified，这是我在set in stone之前所做的）准备好了
然后，正如你在分钟中看到的，我们担心的是我们可能会因为make_unique而移动得太快。 N3588在会前邮寄时间，但这是它第一次出现 - 几乎所有提案需要超过一次会议从第一次出现转变为正式议案（我的第一个提案，透明运营商函，一个更不寻常的例外，因为它出现，并被投票在没有改变波特兰）。这是一个完全有效的关注，顺便说一句。最后，投票通过 - 成员不必解释他们的投票，但我的意思是，这是一个非常小的建议，没有人反对实际内容，一个实施可用的组合。 p>
现在我要再次考虑make_shared的所有这些东西了。
Stephan T Lavavej's initial proposal for make_unique was N3588
It included the following functions:
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...)
However, the final propsal, N3656, only includes make_unique (both forms). I am unable to find any discussion on the other forms of the function. I read the minutes of the Bristol meeting, but they don't even reference the original proposal.
Why were these extra functions not included in the final draft?
I read the minutes of the Bristol meeting, but they don't even reference the original proposal.
The minutes are accurate. N3588 (original recipe, without Standardese) was not discussed in the full committee, only N3656 (extra crispy, with Standardese) was discussed there. If you haven't been to a meeting, this might seem strange, but what happens is that the Working Groups (Core, Evolution, Library, Library Evolution) and the Study Groups (Filesystem, etc.) work during the week in parallel, eventually conducting straw polls (where anyone can vote) to determine what should be brought to the full committee. On the second to last day, the full committee (100+ people) meets, where the formal motions are briefly discussed, and straw polls (where only voting members may vote) are taken. If anyone is concerned that features aren't baked enough, or that there will be integration problems with other features, etc. then this is discussed here - but the full committee doesn't look at the microscopic details of a proposal. Basically if something is controversial enough to warrant that, it won't survive a vote anyways, so it'll be withdrawn from consideration for that meeting. Then on the last day, the full committee meets again, and the real votes are taken (voting members only). In general there should be no surprises during the real votes, since the day before was a test run.
The LWG minutes aren't publicly available, but I can tell you what happened. N3588 deliberately contained no Standardese - what I did there was explore the design space, figuring out what new-expressions we should imitate, and arguing for or against various things. I was planning to receive feedback from the LWG, then draft Standardese for the next meeting (Chicago), since writing up anything complicated takes me a lot of time to get exactly right (it takes more time than actually implementing it, since Standardese carefully dances around implementation details like SFINAE). While presenting the proposal, I explained how I was not a great fan of default-init (which I deride as garbage-init), but had outlined how it could be done anyways. I also explained that I had learned more about the array-init cases since writing the proposal (while receiving feedback from MS devs). Interestingly, the Core Language provides sequencing guarantees for braced-init-lists, so new X[3]{ f(), g(), h() } calls those functions left-to-right. Function calls don't get those guarantees, which (in my opinion) mortally wounds attempts to wrap array-init like in my original proposal. There are clever ways to achieve the sequencing guarantees with slightly different user syntax and even more implementation complexity, which I explained to the LWG. At this point, I really wanted to drop array-init, and I was lukewarm on default-init (which is easy to specify and implement, but I view it as essentially unnecessary). The LWG's reaction was that they wanted the simplest forms only - no array-init and not even default-init. I was super happy to hear this, and I was able to write up the necessary Standardese at the meeting itself (at like 4 AM). So that's where N3656 came from. The LWG took another look at it, and with one minor tweak (changing make_unique<T[N]>'s return type from void to unspecified, which I did before it was "set in stone") was ready to bring it to the full committee.
Then, as you saw in the minutes, the concern was that we might be moving too fast with make_unique. N3588 was in the pre-meeting mailing on-time, but this was the first time it had appeared - almost all proposals take more than a single meeting to move from first appearance to formal motion (my first proposal, the transparent operator functors, was an even more unusual exception as it appeared and was voted in without changes in Portland). This was a totally valid concern, by the way. In the end, the vote passed - members don't have to explain their votes, but my sense was that it was a combination of the proposal being very small, nobody having objections to the actual content, and an implementation being available.
Now I'm going to have to think about all this stuff again for make_shared!
这篇关于make_unique数组，原始提案vs. final的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
