Конструктор Constexpr не удовлетворяет требованиям, но по-прежнему constexpr. Почему?

Интересно, что если вы вернетесь, чтобы прочитать предыдущие предложения по этому поводу - например, open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf - вы обнаружите, что формулировка такая, как вы предлагаете.

@JackAidley: Ого, хорошая находка! Я прослежу, может быть, где-то есть обсуждение этого (для других это на странице 13, пункт 5).

Изменение формулировки, похоже, связано с исправлением этого отчета о дефекте, но я не могу понять, почему: open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1358 - может быть, кто-то другой может?

Хм, разве «Дополнительная заметка (январь 2013 г.):» не является темой этого вопроса? Кажется, комитет в курсе?

Боковое примечание: теперь есть Consteval, который ведет себя таким образом.

С пометкой constexpr конструктора шаблонного класса проблем нет. Проблема в том, что когда этот шаблон является специализированным, и компилятор знает, что конструктор не constexpr, он не должен рассматривать его как constexpr. Но из-за этого правила он все равно трактует его как constexpr. А сбой наступит поздно, когда конструктор фактически используется в константном выражении. Но это могло произойти и раньше, когда «поддельный» конструктор constexpr использовался в другом конструкторе constexpr (если бы свойство consexpr было семантически удалено).

Или сбой вообще не происходит, когда конструктор не используется в константном выражении, поэтому будет скомпилирован неправильный код (в случае динамической инициализации вместо статической).

Я думаю, вы неправильно понимаете, что означает constexpr для функций. constexpr функции может должны оцениваться во время компиляции (для некоторого набора аргументов). Это не гарантированный для каждого выбора аргументов. Если вам требуется инициализировать значение во время компиляции, отметьте значение как constexpr (это вызовет проблему). Отметка только функции просто делает законным использование функции в константном выражении, это не требует, чтобы каждый вызов выполнялся во время компиляции.

Конечно, но текущие компиляторы выдают ошибку (даже если это отчет о недоставке), когда случай тривиален, а выражение никогда не дает constexpr. Но из-за этого правила (якобы) они этого не делают.

@geza Покажите, пожалуйста, такой случай. Обратите внимание, что функции, помеченные как constexpr, нарушающие пункты списка здесь, должны быть диагностированы. Компилятор может (но не требуется) для дополнительной диагностики случаев, когда никакой набор аргументов не может привести к оценке времени компиляции («Диагностика не требуется для нарушения этого маркера.»). Обратите внимание, что ключевое слово используется для того, чтобы компилятор помогал вам, а не для того, чтобы компилятор делал то, что в противном случае он бы не сделал.

Посмотрите на код здесь: stackoverflow.com/questions/53632120/…. Поместите член NonConstexpr в Foo. Тогда он больше не будет компилироваться (проверено с помощью gcc и clang).

Ознакомьтесь с комментариями под вопросом: Джек Эйдли нашел более старое предложение, где оно сработало так, как было бы логично (для меня). Но, возможно, это предложение сильно отличалось и в других отношениях. Но в любом случае они это изменили из-за чего-то.

Я имел в виду пример «текущий компилятор выдает ошибку в тривиальном случае». То, что вы связали, - это просто демонстрация всего, что было сказано до сих пор, и у меня не хватает способов сформулировать это. Что касается «почему они изменили это предложение», см. Начало моего ответа для обоснованного предположения. Или, скорее, позвольте мне спросить вас: если бы constexpr работал так, как вы (и исходное предложение) хотели, сколько конструкторов std::pair должно было бы быть? У скольких из них будет одинаковый код?

Это пример того. Если вы добавите элемент NonConstexpr в Foo, он не будет компилироваться. Тривиальный пример: Foo не помещается в константное выражение, но не может быть скомпилирован, поскольку конструктор Foo никогда не может быть частью константного выражения.

Для std::pair никаких изменений не потребуется.

@geza: Тогда непонятно, что ты вообще предлагаешь. Если применение constexpr к конструктору класса шаблона, который создается с типом, в котором невозможно быть constexpr, приводит к ошибке компиляции, как сделать такой тип условно constexpr без дублирования конструкторов и использования гимнастики SFINAE?

@NicolBolas: Хм, может, я не вижу здесь ничего тривиального. constexpr написан для конструктора шаблона (как сейчас). Но если специализация приведет к конструктору, не являющемуся constexpr, то constexpr будет проигнорирован. Также как если бы этого не было там написано. Также как говорится в этом старом предложении. Могу ли я упустить из виду что-то здесь, что делает это нежизнеспособным?

@geza: Если это то, о чем вы просите, чем это функционально отличается от того, что у нас есть сейчас?

@NicolBolas: Это будет означать, что мой текущий пример не будет компилироваться, поскольку текущие компиляторы диагностируют тривиальные случаи.

@geza: Если «мой текущий пример» относится к вопросу, на который вы ссылались, то уже не компилируется. Если это не так, то каков ваш текущий пример?

@NicolBolas: хм, какой компилятор? Для меня компилируется. И с помощью gcc, и с помощью clang.

@NicolBolas: gcc, clang, msvc компилирует его, icc отклоняет: godbolt.org/z/ggGfya

@ T.C. Я не могу помочь, но чувствую, что тот, кто решил, что инициализация statics не является статической инициализацией и что Fiasco порядка статической инициализации происходит только при динамической инициализации, а не статической инициализации, в то время немного хихикал.