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

if constexpr выбирает ветвь во время компиляции. В шаблонном коде невыбранная ветвь становится отброшенным оператором и не инстанцируется для конкретного типа, поэтому ошибки, зависящие от этого типа, не возникают.

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

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

До C++17 условную компиляцию внутри шаблонной функции обычно реализовывали через перегрузки, частичную специализацию, tag dispatch или SFINAE. Такие решения работали, но часто распределяли одну логическую операцию по нескольким сущностям и усложняли диагностику ошибок.

if constexpr появился в C++17 как локальный механизм выбора реализации. Он сохраняет обычную структуру функции, но позволяет компилятору исключить неактуальную ветвь до её инстанцирования.

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

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

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

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

Условие if constexpr должно быть контекстуально преобразуемо к bool во время компиляции. После подстановки параметров шаблона компилятор выбирает одну ветвь, а другую рассматривает как отброшенную.

#include <string>
#include <type_traits>

struct Message {
    std::string to_text() const { return "message"; }
};

template<class T>
std::string stringify(T const& value) {
    if constexpr (std::is_integral_v<T>)
        return std::to_string(value);
    else
        return value.to_text();
}

При вызове stringify(42) инстанцируется только ветвь с std::to_string; обращение к to_text для int не проверяется как часть выбранной реализации. При вызове с Message происходит обратное.

Механизм действует именно в шаблонном контексте, где условие или содержащий его оператор связан с параметрами шаблона. Ошибки, не зависящие от конкретного типа, всё равно диагностируются: if constexpr не превращает произвольный некорректный текст программы в допустимый.

Отброшенная ветвь не участвует и в некоторых других свойствах шаблона. Например, при выводе возвращаемого типа функции auto операторы return из отброшенной ветви не учитываются. Однако правила области видимости сохраняются: объявление внутри одной ветви нельзя использовать в другой.

if constexpr не является универсальной заменой концептам. Если нужно выразить требования к публичному интерфейсу шаблона и получить раннюю понятную диагностику, предпочтительнее использовать requires или ограничения шаблона. if constexpr больше подходит для выбора внутреннего алгоритма после того, как тип уже принят.

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

В библиотечном коде одна функция форматировала значения. Для целых типов требовалось стандартное преобразование в строку, а для пользовательских типов — вызов согласованного метода форматирования.

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

Выбран был if constexpr: различие локализовано в одном месте, каждая специализация содержит только применимую операцию, а общий код преобразования результата не дублируется. Для более крупного публичного API дополнительно ввели концепт, чтобы неподдерживаемые типы отклонялись ещё на границе вызова.

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

Достаточно ли написать if constexpr(false) в обычной, не шаблонной функции, чтобы спрятать ошибочный код?

Нет. Вне шаблонного контекста отброшенная ветвь всё равно проверяется по общим правилам корректности программы. if constexpr не является аналогом препроцессорного #if и не предназначен для сокрытия произвольного некорректного кода.
Почему нельзя считать if constexpr полной заменой SFINAE или концептов?

Выбор if constexpr происходит после того, как шаблон уже выбран для рассмотрения и его параметры подставлены. Если тип не должен участвовать в перегрузке вообще, ограничение через концепт или requires выразит это точнее и обычно даст лучшую диагностику.

Кроме того, if constexpr не помогает разрешить неоднозначность между несколькими перегрузками. Он выбирает внутреннюю ветвь уже выбранной функции.
Как if constexpr влияет на вывод возвращаемого типа функции с auto?

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

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