Концепты и ограничения шаблонов (C++20 concepts)

Введение

Статья 541 показала static_assert как раннюю технику ограничения допустимых типов шаблона — C++20 представил concepts, значительно более выразительный, явный и интегрированный в систему типов механизм для той же цели, разбираемый в этой статье как современная, рекомендуемая альтернатива более ранним, менее элегантным техникам.

Концепция

Concept — именованный, явно объявленный набор требований к типу (типы должны поддерживать определённые операции, иметь определённые члены, или удовлетворять более сложным, составным условиям) — concepts используются для ограничения параметров шаблона, заставляя компилятор немедленно, на месте использования шаблона, проверить, удовлетворяет ли переданный тип заявленным требованиям, и дать понятную, точную ошибку компиляции прямо в точке нарушения требования, а не глубоко внутри реализации шаблона (что было типичной, менее удобной диагностикой для шаблонов до появления concepts, статья 541). Стандартная библиотека предоставляет набор готовых, часто используемых concepts (std::integral, std::floating_point, std::same_as), и разработчики могут определять собственные, специфичные для своих задач concepts через concept-объявление, комбинирующее несколько требований.

Пример кода: Концепты и ограничения

#include <concepts>
#include <iostream>

template<typename T>
concept Numeric = std::integral<T> || std::floating_point<T>; // собственный concept — комбинация двух стандартных

template<Numeric T> // ограничение параметра шаблона через concept прямо в объявлении
T add(T a, T b)
{
    return a + b;
}

int main()
{
    std::cout << add(3, 4) << std::endl;      // OK — int удовлетворяет Numeric
    std::cout << add(3.5, 2.1) << std::endl;  // OK — double удовлетворяет Numeric

    // add(std::string("a"), std::string("b")); // ОШИБКА КОМПИЛЯЦИИ — понятное сообщение,
    // указывающее именно на то, что std::string НЕ удовлетворяет concept Numeric,
    // а не глубокая, неясная ошибка где-то внутри реализации функции add
    return 0;
}

// requires-выражение для более сложных, составных требований к типу
#include <concepts>
#include <iostream>

template<typename T>
concept Printable = requires(T value) { // requires — проверка, что указанное выражение КОРРЕКТНО для типа T
    std::cout << value; // требование: должна существовать возможность вывести значение этого типа через <<
};

template<Printable T>
void printValue(T value)
{
    std::cout << "Значение: " << value << std::endl;
}

// auto с concept — упрощённый синтаксис ограниченного параметра без явного template<>
void processNumber(Numeric auto value) // современный, компактный синтаксис C++20 — эквивалент template<Numeric T>
{
    std::cout << value * 2 << std::endl;
}

Пояснения к коду

concept Numeric = std::integral<T> || std::floating_point<T>; показывает определение собственного concept через логическую комбинацию двух готовых, стандартных concepts — Numeric истинен для любого типа, удовлетворяющего хотя бы одному из этих двух условий (целочисленный ИЛИ вещественный тип). template<Numeric T> T add(T a, T b) показывает применение этого concept для ограничения параметра шаблона — попытка вызвать add с типом, не удовлетворяющим Numeric (как std::string), даёт сразу понятную, точную ошибку компиляции именно о нарушении этого конкретного, явно названного требования, что значительно более информативно, чем неясная, глубоко вложенная ошибка, типичная для шаблонов без явных ограничений (статья 541). requires(T value) { std::cout << value; } показывает более общую, гибкую форму concept через requires-выражение — вместо комбинации именованных, готовых concepts, здесь явно указывается конкретное выражение (std::cout << value), которое должно быть синтаксически корректным для типа T, что даёт большую гибкость для выражения произвольных, специфичных требований, не сводимых к простой комбинации существующих concepts. Numeric auto value показывает сокращённый, современный синтаксис, объединяющий вывод типа auto (статья 544) с ограничением через concept в одном компактном выражении, эквивалентном более многословному template<Numeric T> void processNumber(T value).

Подводные камни

Чрезмерно широкие или, наоборот, чрезмерно узкие концепты, не точно отражающие реально нужный набор требований для корректной работы шаблона — concept, требующий значительно больше, чем реально нужно функции (излишне ограничивающий допустимые типы), необоснованно сужает применимость шаблона, тогда как concept, требующий меньше, чем реально использует функция внутри своей реализации, не предотвращает все возможные ошибки несовместимости типов на раннем этапе, частично возвращая к менее удобной диагностике, типичной для шаблонов без достаточно полных ограничений.
Игнорирование возможности переноса существующего кода на С++20 concepts с более старых техник ограничения (static_assert, SFINAE статьи 554) без оценки, действительно ли проект уже использует C++20 как минимальный поддерживаемый стандарт — concepts требуют C++20, и для проектов, поддерживающих более старые стандарты (что особенно типично для embedded-разработки, статьи 351-360, где компиляторы для специфичных платформ часто отстают от новейших стандартов), переход на concepts невозможен без отказа от поддержки этих более старых стандартов, и решение о использовании concepts должно явно учитывать реальные требования к минимальной поддерживаемой версии стандарта C++ для конкретного проекта.
Создание глубоко вложенных, сложных составных концептов, теряющих исходную ясность и понятность, ради которой concepts изначально были введены как альтернатива менее явным техникам — хотя concepts технически поддерживают сложную композицию через логические операторы и requires-выражения, чрезмерное усложнение определения отдельного concept может частично нивелировать saму цель улучшения читаемости и диагностики, ради которой concepts применяются, и разумная простота отдельных концептов (возможно, через композицию из нескольких простых, явно названных concepts, как Numeric из примера) обычно предпочтительнее одного, чрезмерно сложного, монолитного concept.
Предположение, что concepts полностью заменяют необходимость в тестировании (основной цикл статей про тестирование) шаблонного кода — concepts проверяют лишь синтаксическую совместимость типа с заявленными требованиями (что тип поддерживает нужные операции), но не проверяют семантическую корректность поведения этих операций для конкретного типа (правильно ли, например, реализован оператор < для пользовательского типа с точки зрения ожидаемой семантики сравнения), и полноценное тестирование шаблонного кода для реально используемых конкретных типов остаётся необходимым даже при использовании самых строгих и подробных concepts.