Требуются ли в руководствах по дедукции спецификаторы noexcept?
По некоторым причинам я всегда думал, что руководства по дедукции должны иметь такую же noexcept-ность конструктора, на который они ссылаются. Например:
template<typename T>
struct clazz {
clazz(const T &) noexcept {}
};
clazz(const char &) noexcept -> clazz<int>;
То есть, если конструктором является noexcept, и я хочу, чтобы он был таким же и для const char &, я также должен добавить спецификатор noexcept в руководство по выводам.
Сегодня я немного поработал с ICC и обнаружил, что у него проблемы с noexcept на руководствах по дедукции. Все идет нормально. Думал это ошибка компилятора и все.
Однако я изучил стандарт и не смог найти ни одной точки, подтверждающей мое первоначальное предположение. Из-за этого я проверил то же самое против clang, и даже если он работает без проблем, кажется, что noexcept в руководстве по выводам игнорируется в 100% случаев. С другой стороны, тот, который находится в конструкторе, влияет на оба.
Итак, мой вопрос: имеет ли это какой-то смысл или требуется несколько размножаться (если это вообще имеет смысл) noexcept-ность конструктора также для руководства по дедукции, или это бесполезно, и я могу просто избавиться от всего noexcept на руководства по удержанию?
Ответы 1
Грамматика для руководства по дедукции определена в [temp.deduct.guide] / 1 как
explicit-specifier(opt) template-name ( parameter-declaration-clause ) -> simple-template-id ;
и, как видите, он не включает спецификатор исключения.
В этом есть смысл. Руководство по дедукции на самом деле ничего не строит. Он просто используется, чтобы сообщить компилятору, как получить параметры шаблона из набора аргументов. У вас есть двухэтапный процесс: руководство (-я) по дедукции запускает разрешение перегрузки для определения параметров шаблона, а затем конструкторы перечисляются с этими выведенными параметрами шаблона, а разрешение перегрузки запускается для конструкторов.
Итак, clang / gcc / msvc неверны здесь: - /
Итак, грубо говоря, все основные компиляторы ошибаются? Потому что это правда, что его игнорируют, но они принимают это, даже если стандарт явно говорит, что токена там не должно быть.
@ Jarod42 Думаю, что да. Для них имеет смысл разрешить это, поскольку это легко игнорировать, и это не имеет никакого отношения к тому, что происходит.
Что ж, это имеет смысл, но технически это недействительный код.
@skypjack Ага. Это чертовски менее вопиющее, чем принятие GCC по умолчанию VLA.
Справедливо. :)
Итак, на практике отсутствие исключений конструктора заимствовано из основного определения, также в случае руководств по дедукции?
@skypjack Руководству по выводам это совершенно не нужно. Все, что он используется, - это определение параметров шаблона. Как только это будет сделано, разрешение перегрузки запускается снова, чтобы фактически выбрать конструктор.
TIL. На самом деле это имеет смысл. Спасибо за быстрый ответ и дальнейшие объяснения.
@skypjack Пожалуйста. Если у вас есть час, вы должны дать этот разговор часы. Он раскрывает множество мелких деталей и действительно хорошо объясняет все. ИМХО Стефан Т. Лававей проделал большую работу.
Я обязательно это сделаю. Спасибо, что указали на это.
Из cppreference синтаксис
explicit-specifier(optional) template-name ( parameter-declaration-clause ) -> simple-template-id ;; нетnoexcept...