C++20四大之Concept

前言：C++模板的演进 模板的演进是C++发展史中一条十分重要的线，个人觉得Concept是这条线中最大的一个特性了。在介绍Concept之前，我们先捋一捋模板这条线的发展。

timeline
    title C++ Templates Evolution
    1979 : C with Classes - First Implementation
    1988 : First Formal Proposal of Templates
    1998 : Templates Enter the Standard (Function/Class Templates, SFINAE)
    2011 : C++11 Variadic Templates
    2014 : C++14 Variable Templates, Generic Lambda
    2017 : C++17 Template Parameter Deduction, if constexpr
    2020 : C++20 Concepts

据Stroustrup先生回忆， 对模板的设想早在1982年便有了，正式提出是在1998年的 USENIX C++ conference会议上提出，设计模板的初衷是因为当时的C++缺少一个标准库，而当时没有模板的C++很难设计出“vector、list”这种适用于多种类型的容器。 到1998年模板正式进入标准，在这之前C++模板已经是一个图灵完备的语言了——理论上来讲，可以只用模板代码解决任何可计算的问题。用递归实现循环、模板特化、偏特化实现分支判断。例如下面这个模板可以在编译期计算的fibonacci函数：

template<int  N>
int fibonacci() {
  return fibonacci<N-1>() + fibonacci<N-2>(); 
}
template<>
int fibonacci<1>() { return 1; }
template<>
int fibonacci<0>() { return 0; }

SFINAE特性为上述代码的运作提供了保障。两个模板的特化构造了递归的退出条件，“隐式”的实现了if判断的功能。到了C++17，有了if constexpr，上面这段代码可以写的更加“直白”

template<int N>
constexpr int fibonacci(){
  if constexpr(N <= 1)
    return N;
  else
    return fibonacci<N-1>() + fibonacci<N-2>();
}
auto val = fibonacci<5>();

不管是SFINAE、std::enable_if、还是if constexpr，其实都在做一件事：使编译期if的使用更加直白易用。编译期if可以用来判断数值，如fibonacci模板，更多的时候是用来判断“类型”，std::enable_if便是如此。

template <typename T, std::enable_if_t<std::is_enum<T>::value, bool> = true>
void func(const T& value) {
  //当T是枚举类型时，匹配当前模板函数
  .......
}
template <typename T, std::enable_if_t<std::is_arithmetic<T>::value, bool> = true>
void func(const T& value) {
  //当T是数值类型时，匹配当前模板函数
  .......
}

func有一个重载，func的内部逻辑需要区分value的类型：enum跟数值类型分开处理。为了使编译器能够在实例化时匹配到正确的函数模板，我们用std::enable_if_t这一长串的代码，功能实现了，但代码十分冗长、可读性不好。 此时concept可以登场了。

1，什么是concept ——对T的约束(的集合) 通过一个简单的例子来展示“对T的约束”

template<typename T>
concept Integral = std::is_integral<T>::value;

template<Integral T> 
bool equal(const T& a, const T& b){
    return a == b;
}

函数模板equal返回两个值是否相等，这个操作不能用在浮点类型中。为防止该模板被float等浮点类型实例化，使用一个Integral concept来约束T——也就是强制保证该模板只能使用整数类型实例化。 函数模板equal的T不再是一个“typename”，变成了“Integral”，显然语义上Integral更精准。当我们试图用浮点类型实例化时，会给出错误：

auto value_a = equal(1, 3);       //OK
auto value_b = equal(0.11, 0.33); //ERROR

equal(0.11, 0.33) 会在编译时报错：

2，我们为什么需要concept 假如使用std::enable_if来实现上述功能，可以从代码可读性以及报错信息两个方面来感受concept的便捷： 1，更好的代码可读性

template<typename T, std::enable_if_t<std::is_integral<T>::value, bool> = true>
bool equal_2(const T& a, const T& b){
    return a == b;
}

使用concept约束T，比使用enable_if更加简洁、符合自然语义。 2，减少重复代码 使用std::enable_if进行类型约束容易出现大量的重复代码，而concept则很容易重复利用。 3，更清晰、更直接的报错信息 concept不满足时编译器会直接告知哪个concept未满足，enable_if实现方式的报错更像是“隔靴搔痒”

3，约束T的四种语法形式

template<my_concept T>
void func(T t);

void func(my_concept t);

template<typename T> requires my_concept<T>
void func(T t);

template<typename T> 
void func(T t) requires my_concept<T>;

第二种无疑是最简洁、最符合自然语义的写法了。后两种使用了requires关键字，这种方式称为“require-clause”（require子句），可以方便的组合多个concept:

template<typename T> requires concept_a<T> && concept_b<T> || sizeof<T> == 4
void func(T t);

4，内置concept <concepts>头文件内置了常用的concept，可以满足大多数日常开发需求： 这些concept可分语言核心concept、为比较concept、对象concept、调用concept、迭代器concept、范围concept

Concepts

5，定义自己的concept 假如遇到了<concepts>头文件内的concept无法满足实际需求的 场景，我们就需要定义自己的concept：

template <template-parameter-list >
concept concept-name = constraint-expression;

值得注意的是，concept的定义，不能递归、不能在定义时被其他concept约束

template<typename T>
concept V = V<T*>; // Error: 不能递归定义
 
template<C1 T>
concept Error1 = true; // Error: 不能被其他concept约束

template<class T> requires C1<T>
concept Error2 = true; // Error: 不能被其他concept约束

若concept的template-parameter-list声明的形参大于一个，则使用concept时实参列表需比形参列表少1：

template <typename T, typename B>
concept Derived = std::is_base_of<B, T>::value;
template<Derived<Base> T>
void f(T param);

6，requires关键字 我们在第3节中已经介绍过requires关键字，它可以引出一个“require-clause”（require子句）来实现约束，require子句可以配合 && 、|| 操作符灵活组合多个约束。 除了require-clause之外，requires关键字还有另外一种用法，那就是require-expression：

requires {requirement-seq}
requires (parameter-list) {requirement-seq}

template<typename T> 
concept C = requires(T x, T y) {
  //////////////////////////简单约束////////////////////////////
  x+y;            // x+y有意义(x与y可以相加) 
  T::func();      // T类型定义了静态方法func(public)
  x.func2();      // T类型定义了非静态方法func2(public)
  &x;             // x可以取地址 
  sizeof(T) == 10;// sizeof(T)可以与10比较——该约束永远为成立 
   
  //////////////////////////类型约束////////////////////////////
  typename T::MyType; //  MyType是T内定义的一个内置类型(public) 
  
  //////////////////////////复合约束////////////////////////////
  //1, x.func() 合法(func是x的成员方法)
  //2, MyType在T内有定义
  //3, func()的返回值可以转换为MyType
  {x.func()} -> std::convertible_to<typename T::MyType>; 
  //x.func() 合法且不会抛出异常
  {x.func()} noexcept;      
  {*x};
  
  //////////////////////////嵌套约束////////////////////////////
  requires MyConcept<T>;    //T满足MyConcept概念的约束
  requires (sizeof(T) == 4);//T的对象占用4字节内存                             
};

使用requires-expression可以定义逻辑非常复杂的concept，()内是参数列表——是可省略的，{}内是约束列表。约束列表中的表达式会在编译器检查其合法性（并不是求表达式的值，只是做一个可行性检查），结果是true或者false。若约束列表中的表达式都能通过，则本条requires表达式的值为true。在本例中，x+y; 约束并不会真的相加求值，而是要求x与y是“可相加的”。 约束列表中的约束可以分为四类：

1. 简单约束：一个随意的表达式，编译器只检查其语法合法性。x+y; 便是一个简单约束。
2. 类型约束: 以typename开头，后跟随一个类型名。
3. 复合约束: 形如{ expression } noexcept(可略) -> return-type-requirement(可略) ;编译器会检查expression的合法性，假如noexcept有被使用，编译器还会检查expression有无潜在的抛出异常的可能，最后，假如return-type-requirement没被省略，则检查exp
4. 嵌套约束: 以requires关键字开头，后跟其他约束表达式

后语：

在查阅资料时与concept一起出现的还有constraints一词，该词意为“约束”，这两个名词经常让人迷糊，个人觉得可以这样理解：

1. concept是手段，是实现约束的手段，constraints——约束才是目的。
2. concept的本质是一个集合——该集合内定义了一个或多个“条件”，编译期将这些“条件”实施到T上，若T不满足这些“条件”中的任何一个则给出编译错误，这个过程便是约束。
3. concept之于模板的意义，恰似模板之于普通代码的意义。后者将某个具体类型泛化成T，前者则给T以约束。