为什么 [=]{} 有 lambda 捕获？

Question

在直观的层面上，不需要携带任何状态（通过引用或其他方式）的 lambda 应该可以干净地转换为裸函数指针是有道理的。然而，我最近惊讶地发现 GCC、Clang 和 MSVC 中出现以下错误：

int main(int, char *[]) {
    void (*fp)() = []{}; // OK
  //fp = [=]{};          // XXX - no user defined conversion operator available
  //fp = [&]{};          // XXX - same ...
}

C++17 规范（或至少 visible public draft version N4713）在第 8.4.5.1 节的第 7 项中引用了 [expr.prim.lambda.closure] 对带有和不带有捕获的 lambda：

非泛型 lambda 表达式的闭包类型没有 lambda 捕获，其约束（如果有）得到满足，具有一个转换函数指向具有 C++ 语言链接 (10.5) 的函数的指针与闭包类型的函数调用运算符相同的参数和返回类型。 ...

但是，查看正式语法，您可以在第 8.4.5 节中看到以下内容[expr.prim.lambda]：

• lambda 表达式：
  • lambda-introducer 复合语句
  • ...
• lambda-introducer：
  • [lambda-capture_opt]
• ...

并在 § 8.4.5.2 [expr.prim.lambda.capture]：

• lambda 捕获：
  • 默认捕获
  • 捕获列表
  • 默认捕获，捕获列表
• 默认捕获：
  • &
  • =

因此，令我沮丧的是，所有编译器实际上都在遵守法律条文......

为什么语言将捕获的存在定义为声明中的一种狭义语法区别，而不是基于主体是否包含对任何非静态/捕获状态的引用？

Answer 1

允许转换的更改是由国家机构评论发起的。见n3052: Converting Lambdas to Function Pointers，指的是国家机构comment UK 42：

具有空捕获列表的 lambda 与常规函数类型具有相同的语义。通过要求这种映射，我们得到了一个有效的 lambda 类型，它具有一个已知的 API，它也与现有的操作系​​统和 C 库函数兼容。

N3052 的分辨率是：

解决方案：添加新段落：“具有空捕获集的 lambda 表达式应可转换为指向函数类型 R(P) 的指针，其中 R 是返回类型，P 是 lambda 的参数类型列表表达。”此外，（a）允许转换为函数引用和（b）允许外部“C”函数指针类型可能会很好。

...

在第 5 段之后添加一个新段落。此编辑的目的是为没有 lambda 捕获的 lambda 获得闭包到函数指针的转换。

没有 lambda 捕获的 lambda 表达式的闭包类型具有一个公共的非虚拟非显式 const 转换函数，该函数指向具有与闭包类型的函数调用运算符相同的参数和返回类型的函数的指针。这个转换函数的返回值应该是一个函数的地址，当被调用时，它与调用闭包类型的函数调用运算符具有相同的效果。

这就是我们今天所处的位置。请注意评论说empty capture list，我们今天所拥有的似乎与评论中措辞的意图相符。

看起来这是基于国家机构评论的修复，并且应用范围很窄。

Answer 2

您提出的规则非常脆弱，尤其是在 P0588R1 之前的世界中，当隐式捕获依赖于 odr 使用时。

考虑：

void g(int);
void h(const int&);

int my_min(int, int);

void f(int i) {
    const int x = 1, y = i;
    [=]{ g(x); }; // no capture, can convert?
    [=]{ g(y); }; // captures y
    [=]{ h(x); }; // captures x
    [=]{ my_min(x, 0); }; // no capture, can convert?
    [=]{ std::min(x, 0); }; // captures x
}