为了具体,在下面的例子中我们有
void f(int&& i) {}
int i = 0;
f(i); // error,looks for f(int&)
f(0); // fine,calls f(int&&)
和
template <typename T>
void f(T&& test) {}
int i = 0;
f(i); // fine,calls f(T&&) with T = int& (int& && = int&)
f(0); // fine,calls f(T&&) with T = int&& (int&& && = int&&)
但是如果我们使用概念会怎么样？
template <typename T>
requires Number<T>
void f(T&& test) {}
template <Number T>
void g(T&& test) {}
void h(Number&& test) {}
int i = 0;
f(i); // probably should be fine?
f(0); // should be fine anyway
g(i); // probably also fine?
g(0); // fine anyway
h(i); // fine or not?
h(0); // fine anyway
特别是最后一个例子让我有些困扰,因为有两个冲突
原则.首先,以这种方式使用的概念应该像一种类型一样工作,第二种是如果T是推断类型,T&&表示通用引用而不是右值引用.
感谢提前澄清这一点！
解决方法
另一方面,文件N4263 Toward a concept-enabled standard library是标准委员会的一些成员的意图声明,它表明了在Concept-Lite是一个单独的TS之后的自然步骤,将概念添加到标准库中,以限制例如.算法.
那TS可能在路上有点远,但是我们仍然可以看看到目前为止写的概念.我看到的大多数例子都有一个悠久的传统,其中一切都围绕一种推定的候选类型,通常不会被认为是参考类型.例如,一些较旧的Concepts-Lite草案(例如N3580)提到了诸如Container的概念,它们的根源在SGI STL,甚至在标准库中仍然存在23.2容器要求的形式.
相关类型的描述如下所示：
Value type
X::value_typeThe type of the object stored in a container. The value type must be Assignable,but need not be DefaultConstructible.
如果我们将这个天真地转化为Concepts-Lite,它可能如下所示：
template<typename X>
concept bool Container = requires(X x) {
typename X::value_type;
// other requirements...
};
在这种情况下,如果我们写
template<typename C>
requires Container<C>
void example(C&& c);
那么我们有以下行为：
std::vector<int> v; // fine // this checks Container<std::vector<int>>,and finds // std::vector<int>::value_type example(std::move(v)); // not fine // this checks Container<std::vector<int>&>,and // references don't have member types example(v);
有几种方式来表达正确处理这种情况的value_type要求.例如.我们可以将需求调整为typename std :: remove_reference_t< X> :: value_type.
我相信委员会成员都知道情况.例如.安德鲁·萨顿(Andrew Sutton)在他的一个概念图书馆中留下了一个insightful comment,展示了确切的情况.他的首选解决方案是将概念定义保留在非引用类型上,并删除约束中的引用.对于我们的例子：
template<typename C>
// Sutton prefers std::common_type_t<C>,// effectively the same as std::decay_t<C>
requires<Container<std::remove_reference_t<C>>>
void example(C&& c);