为什么在未赋值的操作数中不允许lambda表达式，但在常量表达式的未赋值部分中允许lambda表达式？

Question

如果我们看一下C标准草案第5.1.2节，第2段说：

对lambda表达式的求值会产生一个prvalue临时（12.2）。这个临时称为闭包对象。lambda表达式不得出现在未求值的操作数中（第5条）。[注意：闭包对象的行为类似于函数对象（20.8）。-结束注释]

和节5.19常量表达式第2段说：

条件表达式是核心常量表达式，除非它涉及以下其中一个作为潜在求值子表达式（3.2），但不考虑未求值的逻辑AND（5.14）、逻辑OR（5.15）和条件（5.16）运算的子表达式[…]

并有以下要点：

-lambda表达式（5.1.2）；

那么，为什么在未赋值的操作数中不允许lambdas表达式，但在常量表达式的未赋值部分中允许lambdas表达式呢？

我可以看出，对于未赋值的操作数，在几种情况下（decltype或typeid），类型信息不是很有用，因为每个lambda都有一个唯一的类型。虽然我们不清楚为什么要在常量表达式的未赋值上下文中允许它们，也许是为了允许SFINAE？

Answer 1

C标准核心语言缺陷报告和接受的问题#1607中介绍了未评估操作数排除的核心原因。模板参数中的Lambdas旨在澄清此限制，并在5.1.2节中说明限制的意图是：

[...]避免在函数模板签名中处理它们的需要[...]

由于问题记录了当前的措辞，实际上有一个漏洞，因为常量表达式允许它们在未评估的上下文中使用。但它没有明确说明这种限制的理由。避免名称混乱的愿望很突出，你可以推断，避免延长SFINAE也是需要的，因为提议的决议寻求收紧限制，即使有几个可行的替代方案会允许SFINAE。5.1.2第2段的修改版本如下：

lambda表达式不得出现在未计算的操作数（第5条[exr]）、模板参数、别名声明、typedef声明或函数或函数模板在其函数体和默认参数之外的声明中[注意：目的是防止lambda出现在签名中-结束注释]。[注意：闭包html" target="_blank">对象的行为类似于函数对象（20.10[function.objects]）。-结束注释]

该提案已被接受，并在N3936中（有关链接，请参阅此答案）

以更明确地讨论避免将lambda作为未赋值操作数的原理。讨论题为“lambda表达式在comp上未经评估的上下文中不被允许的理由”。lang.cpp。主持人丹尼尔·克鲁格勒列举了三个原因：

1. 可能的SFINAE病例的极端扩展：

[...]它们被排除在外的原因正是因为sfinae案例的这种极端扩展（你正在为编译器打开一个潘多拉盒子）[…]

在许多情况下，这是无用的，因为每个lambda都有一个唯一的类型，假设的例子如下：

template<typename T, typename U>
void g(T, U, decltype([](T x, T y) { return x + y; }) func);

g(1, 2, [](int x, int y) { return x + y; });

声明和调用中lambda的类型不同（根据定义），因此这无法工作。

名称损坏也成为一个问题，因为一旦在函数签名中允许lambda，lambda的主体也必须损坏。这意味着制定规则来破坏每一条可能的语句，这至少会给某些实现带来负担。