make_unique arrays, original proposal vs. final

Question

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?

Answer 1

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!