массивы make_unique, оригинальное предложение против финального

Первоначальное предложение Стефана Т Лававея для 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 (обе формы). Я не могу найти никаких дискуссий о других формах функции. Я читаю протокол встречи в Бристоле, но они даже не ссылаются на оригинальное предложение.

Почему эти дополнительные функции не были включены в окончательный вариант?

14

Решение

Я прочитал протокол встречи в Бристоле, но они даже не ссылаются на первоначальное предложение.

Протокол точен. N3588 (оригинальный рецепт, без Standardese) не обсуждался в полном составе комитета, там обсуждался только N3656 (очень хрустящий, с Standardese). Если вы не были на собрании, это может показаться странным, но происходит то, что рабочие группы (Core, Evolution, Library, Library Evolution) и Study Groups (Файловая система и т. Д.) Работают в течение недели параллельно, в конце концов, проводить опросы соломы (где каждый может голосовать), чтобы определить, что следует довести до полного комитета. Со второго по последний день заседает полный комитет (более 100 человек), на котором кратко обсуждаются официальные предложения и проводятся солидарные опросы (где могут голосовать только голосующие участники). Если кто-то обеспокоен тем, что функции недостаточно выпечены, или что возникнут проблемы с интеграцией с другими функциями и т. Д., То это обсуждается здесь, но весь комитет не рассматривает микроскопические детали предложения. В принципе, если что-то достаточно спорное, чтобы гарантировать, что она не выдержит голосование в любом случае, так что он будет снят с рассмотрения на эту встречу. Затем в последний день вновь собирается полный комитет, и принимаются реальные голоса (только для членов с правом голоса). Вообще не должно быть сюрпризов во время реальных голосований, так как накануне был тестовый заезд.

Протокол LWG не является общедоступным, но я могу рассказать вам, что случилось. N3588 намеренно не содержал стандартов — то, что я сделал, — это исследовал пространство дизайна, выяснил, каким новым выражениям мы должны подражать, и спорил за или против различных вещей. Я планировал получить обратную связь от LWG, а затем подготовить черновик Standardese для следующей встречи (Чикаго), так как написание чего-либо сложного занимает у меня много времени, чтобы понять все правильно (на это уходит больше времени, чем на самом деле, поскольку Standardese тщательно танцует вокруг детали реализации как SFINAE). Представляя предложение, я объяснил, как я не был большим поклонником default-init (который я высмеиваю как garbage-init), но обрисовал в общих чертах, как это можно сделать в любом случае. Я также объяснил, что узнал больше о случаях инициализации массива с момента написания предложения (при получении отзывов от разработчиков MS). Интересно, что Базовый язык обеспечивает гарантии последовательности для фигурных скобок-init-списков, поэтому новые X [3] {f (), g (), h ()} вызывают эти функции слева направо. Вызовы функций не получают тех гарантий, которые (на мой взгляд) смертельно ранили попытки обернуть array-init, как в моем первоначальном предложении. Существуют умные способы достижения гарантий последовательности с немного отличающимся пользовательским синтаксисом и еще большей сложностью реализации, которые я объяснил LWG. В этот момент я действительно хотел отбросить array-init, и я был чуть теплее по умолчанию-init (который легко указать и реализовать, но я считаю его по сути ненужным). Реакция LWG состояла в том, что они хотели только самые простые формы — без массива-инициализации и даже не по умолчанию-инициализации. Я был очень счастлив услышать это, и я смог написать необходимые стандарты на самой встрече (примерно в 4 часа утра). Так вот откуда появился N3656. LWG еще раз взглянул на это, и с одним небольшим изменением (изменение make_unique<T [N]>Тип возврата из void в unspecified, который я сделал до того, как он был «установлен в камне»), был готов довести его до полного комитета.

Затем, как вы видели в течение нескольких минут, проблема была в том, что мы можем двигаться слишком быстро с make_unique. N3588 вовремя отправлял рассылку перед собранием, но это было впервые, когда оно появилось — почти все предложения занимают больше чем одну встречу, чтобы перейти от первого появления к формальному движению (мое первое предложение, прозрачные функторы оператора, было еще более необычное исключение, поскольку это появилось и было проголосовано без изменений в Портленде). Между прочим, это было абсолютно обоснованное беспокойство. В конце концов, голосование прошло — участники не должны объяснять свои голоса, но я чувствовал, что это была комбинация предложения, которое было очень маленьким, никто не имел возражений против фактического содержания и доступной реализации.

Теперь мне придется снова подумать обо всем этом для make_shared!

41

Другие решения

Других решений пока нет …