Краткий ответ

void_t использует правило SFINAE: если зависимое выражение внутри аргумента частичной специализации не удаётся подставить, специализация просто исключается из набора кандидатов. Поэтому компилятор выбирает основную специализацию вместо того, чтобы завершить компиляцию ошибкой.

Это работает только для ошибок, возникших в непосредственном контексте подстановки. Ошибки в других местах, например в теле уже выбранной функции, SFINAE не скрывает.

Исторический контекст

До появления концептов шаблонный код часто проверял свойства типа через SFINAE. Разработчикам требовался единый способ выразить проверку вида «у типа есть вложенный тип или допустимо определённое выражение» без ручного написания множества перегрузок.

Идиома обнаружения существовала до стандартизации void_t, но в C++17 появился стандартный шаблон std::void_t, который упростил её запись. В C++20 для новых интерфейсов обычно предпочтительнее концепты: они лучше документируют требования и дают более понятные сообщения об ошибках.

Постановка проблемы

Предположим, библиотеке нужно выбрать одну реализацию для типов, у которых есть вложенный тип value_type, и другую — для остальных. Прямое обращение к отсутствующему value_type обычно является ошибкой компиляции, поэтому проверку нужно встроить в контекст, где такая ошибка приводит к исключению кандидата.

Неверное расположение проверки может привести к жёсткой ошибке вместо выбора запасной реализации. Это особенно опасно в обобщённых библиотеках: проблема проявится далеко от места, где пользователь передал неподходящий тип.

Подробное решение

void_t принимает произвольный набор типов и преобразует его в void, если все аргументы успешно сформированы. Если хотя бы один аргумент зависит от шаблонного параметра и не существует, подстановка завершается неудачей.

#include <type_traits>

template<class T, class = void>
struct has_value_type : std::false_type {};

template<class T>
struct has_value_type<T, std::void_t<typename T::value_type>>
    : std::true_type {};

struct WithType { using value_type = int; };
struct WithoutType {};

static_assert(has_value_type<WithType>::value);
static_assert(!has_value_type<WithoutType>::value);

Для WithType выражение typename T::value_type корректно, поэтому частичная специализация подходит и заменяет основную. Для WithoutType подстановка не удаётся в аргументе частичной специализации; благодаря SFINAE эта специализация отбрасывается, и остаётся std::false_type.

typename здесь сообщает компилятору, что зависимое квалифицированное имя обозначает тип. Само наличие void_t не делает произвольную ошибку безопасной: зависимое выражение должно находиться в непосредственном контексте подстановки, например в параметре шаблона или условии специализации.

Идиому можно применять не только к вложенным типам, но и к выражениям через decltype. Однако сложные проверки ухудшают читаемость, увеличивают время компиляции и могут давать менее понятные диагностики. В современном C++ для публичных требований к типам обычно стоит рассмотреть концепт, оставляя void_t для совместимости, внутренней техники traits или кода до C++20.

Ситуация из практики

В контейнерной библиотеке нужно определить, можно ли использовать T::value_type при построении вспомогательного адаптера. Рассматривались три варианта.

Проверять свойство вручную в каждом месте использования. Это быстро написать, но приводит к дублированию и разным правилам проверки.
Использовать перегрузки с большим количеством enable_if. Такой вариант совместим со старыми стандартами, но сложен для чтения и часто создаёт длинные сообщения об ошибках.
Спрятать проверку в отдельный trait на основе void_t. Он централизует условие, позволяет переиспользовать результат и не ломает компиляцию для неподходящих типов.

Выбран третий вариант, поскольку требовалась совместимость с C++17 и проверка использовалась в нескольких компонентах. В коде, ограниченном C++20, тот же интерфейс разумнее выразить концептом: смысл требования будет виден непосредственно в объявлении, а диагностика станет понятнее.

Что кандидаты часто упускают

1. Чем SFINAE в непосредственном контексте отличается от обычной ошибки шаблонного кода?

SFINAE применяется во время подстановки шаблонных аргументов в ограниченный набор контекстов. Если ошибка возникла там, кандидат удаляется из рассмотрения. Если же шаблон уже выбран и ошибка возникла, например, в его теле или в коде, вызванном из тела, это обычно обычная ошибка компиляции.

Именно поэтому проверку помещают в параметр частичной специализации или функции, а не оставляют внутри реализации. Место возникновения ошибки, а не только её вид, определяет, сработает ли SFINAE.

2. Почему в проверке вложенного типа нужен typename?

Имя, зависящее от шаблонного параметра, может обозначать тип, статический объект или другой член. До подстановки компилятор не всегда способен однозначно определить его категорию, поэтому перед зависимым именем типа требуется typename.

Без него корректное наличие вложенного типа может быть отвергнуто ещё на этапе разбора шаблона. Это будет не тот сценарий SFINAE, на который рассчитывает идиома обнаружения.

3. Можно ли с помощью void_t безопасно проверить любую семантическую характеристику типа?

Нет. void_t проверяет, что указанные типы или выражения могут быть сформированы, но не доказывает полное соответствие поведения ожидаемому контракту. Например, наличие метода ещё не гарантирует, что он возвращает нужный тип, не бросает исключения или сохраняет требуемые инварианты.

Кроме того, нужно учитывать доступность членов, неполные типы, неоднозначные перегрузки и корректность самого выражения в конкретном контексте. Поэтому void_t — это механизм синтаксического обнаружения, а не полноценная проверка семантики.