C++20初体验——concepts

引子

凡是涉及STL的错误都不堪入目，因为首先STL中有复杂的层次关系，在错误信息中都会暴露出来，其次这么多类和函数的名字大多都是双下划线开头的，一般人看得不习惯。

一个经典的错误是给std::sort传入std::list<T>的迭代器：

#include <list>
#include <algorithm>

int main()
{
    std::list<int> list;
    std::sort(list.begin(), list.end());
}

GCC 10.1.0给出如下错误信息（没有开-std=c++20）：

In file included from c:\program files\mingw-w64\include\c++\10.1.0\algorithm:62,
                 from temp.cpp:3:
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_algo.h: In instantiation of 'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = std::_List_iterator<int>; _Compare = __gnu_cxx::__ops::_Iter_less_iter]':
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_algo.h:4859:18:   required from 'void std::sort(_RAIter, _RAIter) [with _RAIter = std::_List_iterator<int>]'
temp.cpp:9:39:   required from here
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_algo.h:1975:22: error: no match for 'operator-' (operand types are 'std::_List_iterator<int>' and 'std::_List_iterator<int>')
 1975 |     std::__lg(__last - __first) * 2,
      |               ~~~~~~~^~~~~~~~~
In file included from c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_algobase.h:67,
                 from c:\program files\mingw-w64\include\c++\10.1.0\bits\char_traits.h:39,
                 from c:\program files\mingw-w64\include\c++\10.1.0\ios:40,
                 from c:\program files\mingw-w64\include\c++\10.1.0\ostream:38,
                 from c:\program files\mingw-w64\include\c++\10.1.0\iostream:39,
                 from temp.cpp:1:
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_iterator.h:500:5: note: candidate: 'template<class _IteratorL, class _IteratorR> constexpr decltype ((__y.base() - __x.base())) std::operator-(const std::reverse_iterator<_Iterator>&, const std::reverse_iterator<_IteratorR>&)'
  500 |     operator-(const reverse_iterator<_IteratorL>& __x,
      |     ^~~~~~~~
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_iterator.h:500:5: note:   template argument deduction/substitution failed:
In file included from c:\program files\mingw-w64\include\c++\10.1.0\algorithm:62,
                 from temp.cpp:3:
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_algo.h:1975:22: note:   'std::_List_iterator<int>' is not derived from 'const std::reverse_iterator<_Iterator>'
 1975 |     std::__lg(__last - __first) * 2,
      |               ~~~~~~~^~~~~~~~~
In file included from c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_algobase.h:67,
                 from c:\program files\mingw-w64\include\c++\10.1.0\bits\char_traits.h:39,
                 from c:\program files\mingw-w64\include\c++\10.1.0\ios:40,
                 from c:\program files\mingw-w64\include\c++\10.1.0\ostream:38,
                 from c:\program files\mingw-w64\include\c++\10.1.0\iostream:39,
                 from temp.cpp:1:
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_iterator.h:1533:5: note: candidate: 'template<class _IteratorL, class _IteratorR> constexpr decltype ((__x.base() - __y.base())) std::operator-(const std::move_iterator<_IteratorL>&, const std::move_iterator<_IteratorR>&)'
 1533 |     operator-(const move_iterator<_IteratorL>& __x,
      |     ^~~~~~~~
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_iterator.h:1533:5: note:   template argument deduction/substitution failed:
In file included from c:\program files\mingw-w64\include\c++\10.1.0\algorithm:62,
                 from temp.cpp:3:
c:\program files\mingw-w64\include\c++\10.1.0\bits\stl_algo.h:1975:22: note:   'std::_List_iterator<int>' is not derived from 'const std::move_iterator<_IteratorL>'
 1975 |     std::__lg(__last - __first) * 2,
      |               ~~~~~~~^~~~~~~~~

太长不看，加三告辞。换个Visual Studio 2019：

Severity	Code	Description	Project	File	Line	Suppression State
Error	C2676	binary '-': 'const std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types<_Ty>>>' does not define this operator or a conversion to a type acceptable to the predefined operator	temp	C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\algorithm	4138
Error	C2672	'_Sort_unchecked': no matching overloaded function found	temp	C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\algorithm	4138
Error	C2780	'void std::_Sort_unchecked(_RanIt,_RanIt,iterator_traits<_Iter>::difference_type,_Pr)': expects 4 arguments - 3 provided	temp	C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\algorithm	4138

虽然错误信息简短许多，但仍不能告诉我们错误的原因（这些是内部原因）。

我们注意到两段错误都提到了operator-，实际上编译器认为错误在于std::sort中会把两个输入迭代器所属类型的实例相减，而std::list<T>::iterator没有重载operator-运算符。这当然不是让我们来重载这个运算符。

STL源码可以提供一些帮助：

  /**
   *  @brief Sort the elements of a sequence.
   *  @ingroup sorting_algorithms
   *  @param  __first   An iterator.
   *  @param  __last    Another iterator.
   *  @return  Nothing.
   *
   *  Sorts the elements in the range @p [__first,__last) in ascending order,
   *  such that for each iterator @e i in the range @p [__first,__last-1),
   *  *(i+1)<*i is false.
   *
   *  The relative ordering of equivalent elements is not preserved, use
   *  @p stable_sort() if this is needed.
  */
  template<typename _RandomAccessIterator>
    _GLIBCXX20_CONSTEXPR
    inline void
    sort(_RandomAccessIterator __first, _RandomAccessIterator __last)
    {
      // concept requirements
      __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
	    _RandomAccessIterator>)
      __glibcxx_function_requires(_LessThanComparableConcept<
	    typename iterator_traits<_RandomAccessIterator>::value_type>)
      __glibcxx_requires_valid_range(__first, __last);
      __glibcxx_requires_irreflexive(__first, __last);

      std::__sort(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
    }

在概念上（conceptually），std::list<T>的迭代器不满足RandomAccessIterator的要求，所以不能用于std::sort。然而_RandomAccessIterator毕竟只是一个名字，编译器不知道它表示哪些要求，更无法据此输出错误信息。

但是从C++20开始，编译器可以掌握这些信息了，不是通过typename后面的那个名字，而是由两个新关键词concept和requires支撑起来的。然后对于上面那个错误，编译器会说：“std::random_access_iterator<std::list<int>::iterator>不成立”（尽管目前我还没有体验过这种编译器）。

如果我们自己写的模板函数对类型有要求，可以在模板参数列表中写出：

#include <iterator>

template<std::random_access_iterator Iter>
void func(Iter _first, Iter _last)
{
    // ...
}

那么std::random_access_iterator是如何实现的呢？

template<typename _Iter>
  concept random_access_iterator = bidirectional_iterator<_Iter>
    && derived_from<__detail::__iter_concept<_Iter>,
                    random_access_iterator_tag>
    && totally_ordered<_Iter> && sized_sentinel_for<_Iter, _Iter>
    && requires(_Iter __i, const _Iter __j,
                const iter_difference_t<_Iter> __n)
    {
      { __i += __n } -> same_as<_Iter&>;
      { __j +  __n } -> same_as<_Iter>;
      { __n +  __j } -> same_as<_Iter>;
      { __i -= __n } -> same_as<_Iter&>;
      { __j -  __n } -> same_as<_Iter>;
      {  __j[__n]  } -> same_as<iter_reference_t<_Iter>>;
    };

意思看得懂，但不会写。别着急，这些语法我们一点点来讲。

requires关键词与需求

对模板参数的需求是嵌套的，深入到最底层，都是通过requires关键词实现的。“s”的存在使代码在英语的语法中更加通顺一点。

requires有两种用法：requires子句（requires-clause）和requires表达式。

requires表达式

requires表达式产生一个bool值，语法为下列之一：

• requires { 一系列requirements（需求） }；

• requires ( 参数列表 ) { 一系列requirements }。

参数列表用于创建一系列一定类型的变量，在requirements中使用。这些变量并不真实存在（只有语法功能），它们的作用域到后面的}为止。

Requirements有四种：简单需求（simple requirements）、类型需求（type requirements）、复合需求（compound requirements）和嵌套需求（nested requirements）。Requirements之间由分号分隔，只有当每个都满足时整个表达式才为true。

我们后面再来看requires表达式怎么用，现在我们要了解的是我们可以提出哪些需求。

简单需求

任意不以requires关键词开头的表达式都可以作为简单需求，当该表达式语法正确时需求满足。由于参数列表中的变量不实际存在，这个表达式当然也不会被求值。

requires (T a, T b)
{
    a + b;
}

类型需求

typename后跟一个类型名成为类型需求，当该类型存在时需求满足。类型需求可以用来检查嵌套类型和模板实例化。

requires
{
    typename T::type;
    typename S<T>;
}

复合需求

复合需求要求一个表达式合法，且结果类型符合一定约束，并可规定noexcept：

{ 表达式 } 可选的noexcept -> concept名 可选的<参数列表>;

后面会讲类型代入concept的规则，毕竟现在连concept都没讲呢。

requires (T x)
{
    {++x} -> std::same_as<T&>;
}

嵌套需求与requires子句

嵌套需求就是requires子句（这句话不太严格，但没有必要纠结它们的区别）。requires后跟一个bool常量成为一个requires子句，仅当该bool常量的值为true时，子句所在的需求被满足，或所在的模板有效。预告一下，把参数代入一个concept可以得到true或false，而一个concept可以包含多个需求，所以嵌套需求就是多条已定义的需求的组合。

requires (T x) // requires表达式
{
    requires true; // requires子句
    requires std::random_access_iterator<T>; // requires子句，std::random_access_iterator是一个concept
    requires requires (std::size_t n) // 第一个是requires子句，后跟bool值；第二个是requires表达式，产生bool值
    {
        x += n;
    };
}

concept

我们一般用concepts（概念）一词指称这一套C++20特性。前面介绍了各种需求，它们写起来比较长，应该用一个名字来概括它，这个名字将成为一个concept。

concept的语法很简单：

template<模板参数列表>
concept 名字 = bool表达式;

bool表达式当然必须是常量表达式，通常是与模板参数列表有关的requires表达式，和其他concept的逻辑组合。concept可以产生bool值，想象一下把concept换成bool当变量模板就可以了。除此以外，concept作为concept可以用在requires子句和requires表达式中。我们稍后再来看其他用法。

concept不能递归引用自己。concept不能单独声明，所以不会出现两个concept相互引用的情况。下一节将介绍的四种约束，concept一个都不能有。

标准库定义了许多concept，分布在<concepts>、<iterator>和<ranges>中。它们中的一些与<type_traits>中is_开头的类型有相同的含义，但名字不同（而且不是仅仅去掉is_）。

分类	名称	功能
语言核心	same_as	与某类型相同
	derived_from	是某类型的子类
	convertible_to	可以转换为某类型
	common_reference_with	与某类型有common_type
	common_with	与某类型有common_reference
	integral	是整型
	signed_integral	是带符号整型
	unsigned_integral	是无符号整型
	floating_point	是浮点类型
	assignable_from	可从某类型赋值
	swappable	可swap
	swappable_with	可与某类型swap
	destructible	可析构
	constructible_from	可由某些类型的参数构造
	default_initializable	可默认初始化
	move_constructible	可移动构造
	copy_constructible	可拷贝构造
比较	equality_comparable	可==比较
	equality_comparable_with	可与某类型==比较
	totally_ordered	可全序比较（==、<、<=等）
	totally_ordered_with	可与某类型全序比较
对象属性	movable	可移动和swap
	copyable	可拷贝且movable
	semiregular	可默认构造且copyable
	regular	equality_comparable && semiregular
可调用	invocable	可用某些类型的参数调用
	regular_invocable	invocable且无状态
	predicate	是bool谓词
	relation	是二元关系
	equivalence_relation	是等价（==）关系
	strict_weak_order	是严格弱序（<）关系

对于最后两个concept，除了有各种可调用的函数的需求以外，==运算符必须满足自反性与对称性，<运算符也类似。这些是句法上无法检查的，所以这两个concept更像是一种规约：如果模板参数被这种concept约束，那么客户调用时传入的参数就得满足这些语义需求。由于concept不能被特化，这一任务只能落到客户肩上，并且我不认为C++能进化出语义检查。

有些资料中的标准库concept是帕斯卡命名（PascalCase）的，因为最初的concept提案中是这样写的，原因可能是为了让它看起来属于新的C++20，或是与模板参数列表中类型大写的习惯一致。后来几个C++元老决定把concept换回C++标准命名法（Rename concepts to standard_case for C++20, while we still can），单词组成也略有修改。后来又有少许修改，以最新标准草稿（写作时为N4868）为准。

约束

现在到了应用concept的时候了。Constraint（约束）指定模板参数的需求，是以下需求的逻辑与：

1. 模板参数前的concept；

   template<Concept T> // `Concept`是一个concept，下同
   void f(T);
   

2. 模板参数列表后的requires子句；

   template<typename T>
       requires Concept<T>
   void f(T);
   

3. 在简略函数模板声明（用auto替代模板类型，C++20特性）中，类型占位符（auto）前的concept；

   void f(Concept auto _arg);
   

   说来惭愧，写C++这么久，我从来没有过简写模板类型为auto的想法，明明是知道泛型lambda的。

4. 在函数声明最后的requires子句。

   template<typename T>
   void f(T) requires Concept<T>;
   

这些requirements当然可以同时存在：

template<Concept1 T>
    requires Concept2<T>
void f(T) requires Concept3<T>;

Concept2<T>和Concept3<T>都在requires子句中，产生true或false，任意一个为false时该实例化无效。

但是如何理解Concept1 T呢？把T插到Concept1的参数列表的最前面，这里为空，所以就是Concept1<T>。另一个应用这一规则的地方是复合需求的返回类型部分，我们写std::same_as<int>，其含义为requires std::same_as<T, int>（但是不能这么写）。

如果模板参数代入时出现了不存在的类型或变量，该约束仅仅是不被满足，而不会产生编译错误。

约束可以用于函数模板、类模板和成员函数，非模板类的非模板成员函数除外。函数模板与类模板的约束是类似的，只有满足约束时模板才能实例化；对于成员函数的约束，如果它作用于模板类的模板参数，当约束不满足时，并不是类模板不能被实例化，而是实例化后的模板类没有这个成员函数：

#include <concepts>

template<std::regular T>
struct Container
{
    template<std::same_as<int> U>
    void f(U u) { }

    void g()
        requires std::same_as<T, int>
    { }
};

int main()
{
    Container<int> ci;
    ci.f(1);
    ci.g();
    Container<double> cd;
    cd.f(1);
    cd.g(); // error
}

像特化和偏特化一样，concept之间存在的包含关系也能用于重载决议——如果A成立则B一定成立，那么实例化时会优先匹配B的那一个实现。但是，concept的包含关系有时会不符合直觉，即两个concept看似包含却不能被编译器发现：

template<class T> constexpr bool is_meowable = true;
template<class T> constexpr bool is_cat = true;

template<class T>
concept Meowable = is_meowable<T>;

template<class T>
concept BadMeowableCat = is_meowable<T> && is_cat<T>;

template<class T>
concept GoodMeowableCat = Meowable<T> && is_cat<T>;

template<Meowable T>
void f1(T); // #1

template<BadMeowableCat T>
void f1(T); // #2

template<Meowable T>
void f2(T); // #3

template<GoodMeowableCat T>
void f2(T); // #4

void g(){
    f1(0); // error, ambiguous:
           // the is_meowable<T> in Meowable and BadMeowableCat forms distinct
           // atomic constraints that are not identical (and so do not subsume each other)

    f2(0); // OK, calls #4, more constrained than #3
           // GoodMeowableCat got its is_meowable<T> from Meowable
}

如果Meowable<T>，那么一定有is_meowable<T>，所以BadMeowableCat<T>也满足，为什么不能判断出Meowable和BadMeowableCat之间的包含关系呢？包含关系作用在由&&和||连接的逻辑表达式上（实际上是合取与析取），通过深入到判断两个原子的（不是&&或||连接的）表达式是否相同从而决定包含关系，而只有相同的concept加上相同的模板参数才是相同，其他表达式即使再长得一样也是不同的。

在上面的例子中，编译器认为BadMeowableCat中的is_meowable和Meowable中的那个不一样，从而两个concept之间没有包含关系，于是f1的重载决议就是二义的；而GoodMeowableCat显然包含了Meowable，所以对f2的调用就是合法的。

另一方面，包含关系的检查一定会深入到最底层的concept，所以没有必要给所有自定义的concept进行非常严格的层次划分。但是有一点是原则性的，就是当你需要不同约束程度的concept时，它们的最底层必须都被有名字的concept封装起来。<type_traits>里有那么多变量模板，<concepts>还要分别用不同的、有些混淆性的名字包装一下，正是因为这个。

模板升级

面向过程、基于对象、面向对象、泛型和函数式这几个编程范式是逐渐加入C++的。起初，C++并没有模板，直到1990年。Bjarne Stroustrup对模板的要求是（以下翻译了跟没翻一样）：

• Full generality/expressiveness

• Zero overhead compared to hand coding

• Well-specified interfaces

后来的实现满足了前两条：针对第一条，C++模板是图灵完全的；针对第二条，C++模板带来更好的运行时性能（相比于qsort或虚函数这一类实现）；唯独第三条没有解决，导致冗长的模板错误，并且衍生出以SFINAE为代表的一些奇技淫巧。它们贯穿我之前写的<functional>系列，成功劝退了很多读者。

C++20带来了解决方案——concept与约束。实际上concept早在零几年就出现在C++标准的草稿里了，但在2009年被删除，没有进入C++11（这一套工具非常复杂，C++20中只是它的简化版）。后来组委会又尝试了concepts lite，但也没有进入C++17。与此同时有一条支线concepts TS在发展，并在GCC中实现了出来，以此积累经验。C++20中的concept与TS还有一定区别，是总结了concept的各种实现以后选择的。

现在我们就来看一下concept如何给模板编程进行升级。以下例子来自meds::function，是我为一个华丽而无用的单片机项目写的库。

Tag Dispatching

首先是还讲点道理的tag dispatching。S是用来放对象的空间的类型，T是要放的对象的类型，一个T能否放进一个S将决定initialize等一系列操作的方法，而object_manager对外提供一个接口，在内部进行分类讨论：

template<typename S, typename T>
class object_manager
{
private:
    using local_storage = std::integral_constant<bool,
            std::is_trivially_copy_constructible<T>::value
        && sizeof(T) <= sizeof(S)
        && alignof(S) % alignof(T) == 0
    >;

public:
    static void initialize(S* _tar, T&& _obj)
    {
        initialize(_tar, std::move(_obj), local_storage());
    }

private:
    static void initialize(S* _tar, T&& _obj, std::true_type )
    {
        new (reinterpret_cast<T*>(_tar)) T(std::move(_obj));
    }

    static void initialize(S* _tar, T&& _obj, std::false_type)
    {
        _tar->template reinterpret_as<T*>() = new T(std::move(_obj));
    }
};

当T可以放进S时，local_storage将成为true_type，匹配到第二个initialize，反之则为第三个。

这种操作还可以接受，但有了concept以后会更好：

template<typename S, typename T>
concept locally_storable = std::is_trivially_copy_constructible<T>::value
                        && sizeof(T) <= sizeof(S)
                        && alignof(S) % alignof(T) == 0;

template<typename S, typename T>
class object_manager
{
public:
    static void initialize(S* _tar, T&& _obj)
    {
        reinterpret_cast<T*&>(*_tar) = new T(std::move(_obj));
    }

    static void initialize(S* _tar, T&& _obj) requires locally_storable<S, T>
    {
        new (reinterpret_cast<T*>(_tar)) T(std::move(_obj));
    }
};

SFINAE

然后就是不讲章法的SFINAE了。下面我们要根据一个类的可比较性调用不同实现，分为两步：function_eq_comp中定义了value指示模板参数T类型的两个实例是否可以用operator==比较，function_object_compare根据其结果执行不同操作。

template<typename T>
class function_eq_comp
{
private:
    using one = int;
    struct two
    {
        one unused[2];
    };

    template <typename U,
        typename = decltype(std::declval<U>() == std::declval<U>())>
    static one test(int);
    template <typename>
    static two test(...);

public:
    static constexpr bool value = sizeof(decltype(test<T>(0))) == sizeof(one);
};

template<typename T>
typename std::enable_if< function_eq_comp<const T&>::value, bool>::type
    function_object_compare(const T& _lhs, const T& _rhs)
{
    return _lhs == _rhs;
}

template<typename T>
typename std::enable_if<!function_eq_comp<const T&>::value, bool>::type
    function_object_compare(const T& _lhs, const T& _rhs)
{
    return false;
}

当==运算符可用时，one test(int)函数正确定义，test函数的返回类型将会是one，value为true，否则one test(int)错误，根据SFINAE，test的调用落入two test(...)，value为false。

当两个const T&不可比较时，function_eq_comp<const T&>::value为false，std::enable_if没有定义type，第一个function_object_compare的模板类型发生错误，根据SFINAE，该重载被忽略；与此同时第二个是可用的。反之，会调用到第一个。与tag dispatching中true_type和false_type并列出现类似，function_eq_comp<const T&>::value与它取!的表达式也都得出现，不能像上面的concept实现那样利用两个函数之间由重载优先级建立起的层次关系。与上一节相比，这里的代码重复更恶心一点。

用concept写会好看很多，尤其是在检查operator==可以用std::equality_comparable的前提下：

template<typename T>
bool function_object_compare(const T& _lhs, const T& _rhs)
{
    return false;
}

template<typename T>
bool function_object_compare(const T& _lhs, const T& _rhs)
    requires std::equality_comparable<const T&>
{
    return _lhs == _rhs;
}

思考题

1. 下面这段代码错在哪？

   template<typename T, typename U>
       requires (T t, U u) { t + u; }
   auto add(T t, U u)
   {
       return t + u;
   }
   

* 2. 查阅资料，写出一个嵌套需求接受但template后requires子句不接受的表达式。（这道题没什么意义，只是想让你去查点资料。）

1. 不查阅资料，判断std::derived_from的两个参数（基类、子类）哪个在前，并给出判断依据。

2. 如何给一个函数添加约束，使得它能接受任意数量的相同类型的参数？

3. 试用concept改写一个void_t技巧的实例。

扩展阅读

Constraints and concepts

C++20: Two Extremes and the Rescue with Concepts等一系列文章

Does constraint subsumption only apply to concepts?

The tightly-constrained design space of convenient syntaxes for generic programming