requires表达式中“validity”含义及简单需求的模板实例化规则

一、场景现象的本质差异 #

你遇到的核心差异源于两个函数模板在concept检查中的不同处理逻辑：func1是返回值为void的函数模板，在requires表达式中调用它属于未求值操作数；而func2带auto返回类型，调用时需要推导返回类型，这会强制触发模板实例化，进而暴露t * 1的编译错误。

先补全你的场景示例代码，方便理解：

#include <concepts>
#include <cassert>

template<typename T>
void func1(T t) { t * 1; } // char*实例化时，函数体内的t*1非法

template<typename T>
auto func2(T t) { return t * 1; } // char*实例化时，同样存在t*1非法问题

template<typename T>
concept C = requires(T t) {
    func1(t); // 用func1时，foo<char*>断言为true
    // func2(t); // 替换为func2时，foo<char*>断言为false
};

template<typename T>
void foo() {
    assert(C<T>);
}

int main() {
    foo<char*>();
}

二、concept简单需求中“validity”的具体含义 #

在C++标准中，concept的简单需求（即requires块内直接书写的表达式，如func1(t)）所断言的“有效性”，指的是：

• 表达式在语法层面合法，且仅通过模板参数推演、语法检查就能确定合法性，不需要执行完整的语义分析或模板实例化。
• 具体到函数模板调用场景：只要能成功推导出模板参数（比如func1的T能被推导出为char*），且调用语法符合函数调用规则，该需求就会被判定为“valid”。此时编译器不会去实例化函数体，因此函数体内的语义错误（比如t * 1的类型不匹配）不会被触发。

简单来说，“validity”只关注表达式能否通过初步的匹配检查，不关心表达式实际执行时的语义合理性。

三、模板实例化的触发规则 #

C++标准中模板的隐式实例化触发场景有明确规定：

1. 函数模板隐式实例化的触发时机：
   • 当必须生成函数的具体代码时才会触发实例化，包括：
     • 函数被实际调用（执行到调用语句）；
     • 需要确定函数的返回类型（如auto返回类型的函数模板，推导返回类型必须访问函数体逻辑）；
     • 函数的地址被取用（需要生成具体函数的内存地址）。
   • 仅进行模板参数推演（如concept中调用func1(t)的场景）不会触发函数体实例化——因为此时只需要确认是否存在匹配的模板，不需要生成函数的具体执行代码。
2. concept需求的特殊处理：
   简单需求属于未求值上下文，编译器仅做语法和推演检查，不会执行表达式，也不会触发依赖于表达式执行的实例化。但如果表达式中存在必须推导的部分（如func2的auto返回类型），推导过程需要访问函数模板的定义，这就会强制触发实例化，进而暴露函数体内的错误。

四、回到你的场景 #

• 对于func1(t)：编译器仅检查能否推导出func1的模板参数T为char*，语法上是合法的函数调用，因此需求判定为有效，C<char*>为true。
• 对于func2(t)：为了推导auto的返回类型，编译器必须实例化func2<char*>的函数体，此时会发现t * 1（即char* * int）是非法运算，因此需求判定为无效，C<char*>为false。

内容的提问来源于stack exchange，提问作者geza