Question

lambda 表达式是函数对象（§4.3.1），因此它们显然可以是模板。有关泛型（多态）lambda 表达式的问题在 C++11 的工作中已经进行了广泛讨论，但当时被认为还没有完全准备好（§4.3.1）。

2012 年，Faisal Vali、Herb Sutter 和 Dave Abrahams 提议了泛型 lambda 表达式 [Vali et al. 2012]。提议的写法只是从语法中省略了类型：

auto get_size = [](& m){ return m.size(); };

委员会中的许多人（包括我）都强烈反对，指出该语法太过特别，且不能推广到受约束的泛型 lambda 表达式中。因此，写法更改为使用 auto 作为标记，指明有类型需要推导：

auto get_size = [](auto& m){ return m.size(); };

这使泛型 lambda 表达式与早在 2002 年就提出的概念提案和泛型函数建议 [Stroustrup 2003; Stroustrup and Dos Reis 2003a,b] 保持一致。

这种将 lambda 表达式语法与语言其他部分所用的语法相结合的方向与一些人的努力背道而驰，这些人希望为泛型 lambda 表达式提供一种独特（超简洁）的语法，类似于其他语言 [Vali et al. 2012]：

C# 3.0 (2007):      x => x * x;
Java 1.8 (~2013):   x -> x * x;
D 2.0 (~2009):      (x) { return x * x; };

我认为，使用 auto 而且没有为 lambda 表达式引入特殊的不与函数共享的写法是正确的。此外，我认为在 C++14 中引入泛型 lambda 表达式，而没有引入概念，则是个错误；这样一来，对受约束和不受约束的 lambda 表达式参数和函数参数的规则和写法就没有一起考虑。由此产生的语言技术上的不规则（最终）在 C++20 中得到了补救（§6.4）。但是，我们现在有一代程序员习惯于使用不受约束的泛型 lambda 表达式并为此感到自豪，而克服这一点将花费大量时间。

从这里简短的讨论来看，似乎委员会流程对写法/语法给予了特大号的重视。可能是这样，但是语法并非无足轻重。语法是程序员的用户界面，与语法有关的 争论通常反映了语义上的分歧，或者反映了对某一特性的预期用途。写法应反映基础的语义，而语法通常偏向于对某种用法（而非其他用法）有利。例如，一个完全 通用和啰嗦的写法有利于希望表达细微差别的专家，而一个为表达简单情况而优化的写法，则有利于新手和普通用户。我通常站在后者这边，并且常常赞成两者同时 都提供（§4.2）。