В шаблонном метапрограммировании: почему std::conditional_t не защищает от ошибки в невыбранном типе, если этот тип уже некорректен при формировании аргументов?
std::conditional_t выбирает один из уже сформированных типов, но не откладывает формирование самих аргументов шаблона. Поэтому некорректный тип в невыбранной ветви всё равно может вызвать ошибку компиляции. Для настоящего отложенного выбора применяют частичную специализацию, SFINAE, ограничения или другую обёртку, которая не формирует опасный тип до момента выбора.
В раннем шаблонном метапрограммировании C++ требовалось вычислять типы во время компиляции и выбирать реализацию в зависимости от характеристик типа. Средства вроде std::conditional появились как универсальный способ выбрать один из двух типов, но они не являются ленивыми вычислителями произвольных выражений типов.
До появления if constexpr и концептов разработчики часто использовали частичные специализации и SFINAE, чтобы не допустить формирования заведомо некорректных типов. Это было особенно важно для type traits и обобщённых библиотек.
Рассмотрим выбор между int и вложенным типом T::value_type. Если T не содержит value_type, второй аргумент std::conditional_t некорректен, даже когда условие гарантированно выбирает int.
Риск состоит в том, что разработчик может ошибочно принять std::conditional_t за конструкцию с ленивым вычислением. В результате шаблон, который должен работать только с безопасной ветвью, перестаёт компилироваться для типов, не поддерживающих невыбранную ветвь.
При инстанцировании псевдонима компилятор сначала должен сформировать все аргументы std::conditional_t: значение условия, первый тип и второй тип. Только после этого реализация std::conditional выбирает результат. Поэтому проверка невыбранной ветви не пропускается.
В варианте с частичной специализацией выбирается специализация select<true, int>. Тело специализации для false не инстанцируется, поэтому обращение к int::value_type не происходит.
Это отличается от SFINAE: SFINAE позволяет исключить декларацию из набора кандидатов при подстановке, но для этого потенциально проблемное выражение должно находиться в контексте, где ошибка действительно превращается в неуспешную подстановку. В обычном аргументе std::conditional_t такой механизм автоматически не возникает.
В современном C++ для функций часто удобнее использовать if constexpr, requires или концепты. Однако if constexpr выбирает ветку внутри тела функции, а для вычисления самого типа обычно нужны специализация, ленивый type trait или отдельный механизм ограничения.
В библиотеке сериализации требовалось определить тип результата: для поддерживаемого контейнера использовать его value_type, иначе — std::byte. Наивная реализация через std::conditional_t обращалась к T::value_type даже для скалярных типов и не компилировалась.
Рассматривались три варианта. if constexpr хорошо подходил для тела функции, но не решал задачу создания отдельного alias-типа. SFINAE и void_t позволяли обнаружить value_type, но усложняли интерфейс. Частичная специализация type trait явно разделила поддерживаемый и резервный случаи.
Выбрали частичную специализацию: она отложила обращение к T::value_type до выбора соответствующей специализации и сделала правила формирования типа очевидными. В результате trait работал и для контейнеров, и для типов без value_type, а диагностика ошибок стала локальной.
1. Является ли std::conditional_t ленивым, если условие известно во время компиляции?
Нет. Ленивым является только выбор результата после формирования аргументов. Известное значение условия не отменяет необходимость корректно сформировать оба переданных типа.
Ленивость можно получить, передавая не сами потенциально опасные типы, а отложенные вычислители — например, специализации traits или шаблонные обёртки. Их содержимое раскрывается только после выбора нужной ветви.
2. Почему частичная специализация решает проблему, а обычный шаблонный класс с двумя полями — нет?
При инстанцировании обычного класса компилятор формирует его выбранное определение целиком. Если в нём безусловно присутствует обращение к T::value_type, ошибка возникнет независимо от того, используется ли соответствующее поле.
Частичная специализация предоставляет разные определения класса. Инстанцируется только подходящая специализация, поэтому опасное обращение может находиться исключительно в ветви, которая реально выбрана.
3. Можно ли решить эту задачу с помощью if constexpr?
Да, если выбор нужен внутри функции, тела переменной или другого контекста, поддерживающего условную компиляцию. Невыбранная ветвь if constexpr не инстанцируется, поэтому находящийся в ней некорректный код обычно безопасен.
Но if constexpr не заменяет type trait, когда результатом должен быть тип, объявленный до тела функции. Для такой задачи применяют частичную специализацию, requires с подходящей структурой или отложенное вычисление типа.