lambda 表达式隐式捕获用“编译器自行推导”这种措辞极度不合适

[Mq-b]

• 位置：book/zh-cn/03-runtime.md

原文：

[&] 引用捕获, 让编译器自行推导引用列表
[=] 值捕获, 让编译器自行推导值捕获列表

“编译器推导” 这种用词通常指代模板等类似语境，绝对不该用在此处。

C++ 的 lambda 表达式隐式捕获规则主要就在于一个是否 ODR 使用，即使是为了简单以及教学目的不严谨的说，也完全可以说是：“编译器会捕获 lambda 表达式中使用到的外围对象”。

文档。

且应当对 [&]、[=] 这种默认捕获符，增加代码示例。

[zwhfly]

尽管“deduce/deduction”(中文“推导”)一词在C++中大多指代“类型推导”，但我不认为这个词被完全征用只用作专有词汇。它仍然可以被用来表达一般意义（即词典意义）上的“推导/推断”。

事实上C++标准文档也会使用deduce这个词的一般意义。在C++23标准文档草案（N4950）中搜索“deduc”，共出现619次。其中绝大多数都表示类型推导（或者类型的一部分），但仍有少数几次被用来表示一般意义上的“推导/推断”。例如：

• [intro.abstract] 脚注5

For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced.

• [dcl.attr.assume] Note 1

The use of assumptions is intended to allow implementations to analyze the form of the expression and deduce information used to optimize the program. Implementations are not required to deduce any information from any particular assumption.

[Mq-b]

这里有更简单，更好，更直接，没有歧义的说法与措辞，无需纠结此问题。

[Mq-b]

且，“编译器会捕获 lambda 表达式中用到的外围对象”，强调一个“捕获使用到的”，这种措辞与指代，也绝对比原文要好的多。原文这里的描述极其模糊，容易误导市面上的其他初学者。

国内的 C++ 开发者中，有一大批人被互联网的错误教学误导，认为 [=]、[&] 这些会让 lambda 捕获外围的所有对象。强调编译器“没有那么愚蠢”，只是捕获“使用到的”，是非常有价值的。

[MrShinshi]

且，“编译器会捕获 lambda 表达式中用到的外围对象”，强调一个“捕获使用到的”，这种措辞与指代，也绝对比原文要好的多。原文这里的描述极其模糊，容易误导市面上的其他初学者。

国内的 C++ 开发者中，有一大批人被互联网的错误教学误导，认为 [=]、[&] 这些会让 lambda 捕获外围的所有对象。强调编译器“没有那么愚蠢”，只是捕获“使用到的”，是非常有价值的。

对, 重点是消歧, 纠正错误以及降低理解障碍. “编译器推导” 这种用词过于暧昧了, 似乎 lambda 具体捕获是个黑盒.

[zwhfly]

这里有更简单，更好，更直接，没有歧义的说法与措辞，无需纠结此问题。

更简单吗？简单的标准是什么？起码字数变多了。

我这里不想评价哪种说法更好，只是纠正一下错误。

我不反对修改，但要“for the right reason”。说“‘编译器自行推导’这种措辞极度不合适”、“绝对不该用在此处”是不对的。后面你又给出了另外的理由——“容易误导”，我也不做评价。但我觉得你至少需要把issue标题改一下。

[Mq-b]

这里有更简单，更好，更直接，没有歧义的说法与措辞，无需纠结此问题。

更简单吗？简单的标准是什么？起码字数变多了。

我这里不想评价哪种说法更好，只是纠正一下错误。

我不反对修改，但要“for the right reason”。说“‘编译器自行推导’这种措辞极度不合适”、“绝对不该用在此处”是不对的。后面你又给出了另外的理由——“容易误导”，我也不做评价。但我觉得你至少需要把issue标题改一下。

如果你评价是否简单是看字数，那我无话可说。

纠正错误？我没有错误。

改标题？没有必要，标题也是我的意思。

[zwhfly]

这里有更简单，更好，更直接，没有歧义的说法与措辞，无需纠结此问题。

如果你评价是否简单是看字数，那我无话可说。

修改建议是你提的，简单也是你说的，按理来说为什么简单应该你来说。说不出来可以不提，没必要堆砌形容词。

原文“编译器自行推导”没有问题。至于推导出所有的还是使用到的，只是没说，并没有误导。用脚趾头想都知道不可能捕获所有的，否则可见的对象可能几百上千个那lambda对象得多大啊。当然多说半句会更清晰，但没有“更简单”。

[zwhfly]

改标题？没有必要，标题也是我的意思。

你的标题和顶楼强调你要修改的原因有两点：
1.你说“推导” 一词用于模板，“绝不该”用在此处。我说这样说是错误的，“推导”当然可以用在此处，在2楼给出了理由。然后你就只说“无需纠结”“我没有错”。
2.你说捕获规则在于 ODR 使用。但这与原文也不冲突啊。

所以你的标题和顶楼完全是无效的。你完全可以把你的真实想法直接说出来，却非要先起个吸引眼球的标题，然后绕个圈到4楼才说出你的真实想法。 连写github issue都要标题党吗？ 指出还不改。这是在浪费作者和关注者的时间。

[MrShinshi]

原文“编译器自行推导”没有问题。至于推导出所有的还是使用到的，只是没说，并没有误导。用脚趾头想都知道不可能捕获所有的，否则可见的对象可能几百上千个那lambda对象得多大啊。当然多说半句会更清晰，但没有“更简单”。

你说的对, 但是我见过太多的人 "没有脚趾头", 不会 "更简单", 但是会 "消除歧义"

[zwhfly]

但是我见过太多的人 "没有脚趾头"

从这点来说，我赞同修改。看作者怎么看了。

[Mq-b]

用脚趾头想都知道不可能捕获所有的，否则可见的对象可能几百上千个那lambda对象得多大啊

您不懂教育，您不懂学习。您只要不说，那就当是这样。

[Mq-b]

原文“编译器自行推导”没有问题

然而我认为就是有问题，有问题就是有问题。有远比它好的以及直接的说明，这无需怀疑。

[Mq-b]

没必要堆砌形容词

当前的描述才是多余，“编译器自行推导”，这句话无存在必要。改成我说的。

[Mq-b]

改标题？没有必要，标题也是我的意思。

你的标题和顶楼强调你要修改的原因有两点： 1.你说“推导” 一词用于模板，“绝不该”用在此处。我说这样说是错误的，“推导”当然可以用在此处，在2楼给出了理由。然后你就只说“无需纠结”“我没有错”。 2.你说捕获规则在于 ODR 使用。但这与原文也不冲突啊。

所以你的标题和顶楼完全是无效的。你完全可以把你的真实想法直接说出来，却非要先起个吸引眼球的标题，然后绕个圈到4楼才说出你的真实想法。 连写github issue都要标题党吗？ 指出还不改。这是在浪费作者和关注者的时间。

1. 我的标题即是我的意思，也是绝对正确的，不存在所谓的“错误”。
2. 我并未表达与原文冲突，我认为原文描述不够清晰，我的话远比原文清晰。
3. “连写github issue都要标题党吗？”我说了，这是我的意思，也是第一感受，无需修改。
4. “指出还不改。”我说了，这是我的意思，没有任何修改的余地。
5. “这是在浪费作者和关注者的时间。”是你在浪费我的时间，本节描述存在大问题，修改余地非常之多，我也只不过是宽泛的提了两点，你是否无视了我最后说的“且应当对 [&]、[=] 这种默认捕获符，增加代码示例。”？

[zwhfly]

用脚趾头想都知道不可能捕获所有的，否则可见的对象可能几百上千个那lambda对象得多大啊

您不懂教育，您不懂学习。您只要不说，那就当是这样。

原文“编译器自行推导”没有问题

然而我认为就是有问题，有问题就是有问题。有远比它好的以及直接的说明，这无需怀疑。

没必要堆砌形容词

当前的描述才是多余，“编译器自行推导”，这句话无存在必要。改成我说的。

改标题？没有必要，标题也是我的意思。

你的标题和顶楼强调你要修改的原因有两点： 1.你说“推导” 一词用于模板，“绝不该”用在此处。我说这样说是错误的，“推导”当然可以用在此处，在2楼给出了理由。然后你就只说“无需纠结”“我没有错”。 2.你说捕获规则在于 ODR 使用。但这与原文也不冲突啊。
所以你的标题和顶楼完全是无效的。你完全可以把你的真实想法直接说出来，却非要先起个吸引眼球的标题，然后绕个圈到4楼才说出你的真实想法。 连写github issue都要标题党吗？ 指出还不改。这是在浪费作者和关注者的时间。

1. 我的标题即是我的意思，也是绝对正确的，不存在所谓的“错误”。
2. 我并未表达与原文冲突，我认为原文描述不够清晰，我的话远比原文清晰。
3. “连写github issue都要标题党吗？”我说了，这是我的意思，也是第一感受，无需修改。
4. “指出还不改。”我说了，这是我的意思，没有任何修改的余地。
5. “这是在浪费作者和关注者的时间。”是你在浪费我的时间，本节描述存在大问题，修改余地非常之多，我也只不过是宽泛的提了两点，你是否无视了我最后说的“且应当对 [&]、[=] 这种默认捕获符，增加代码示例。”？

好一个“绝对正确”。你是邪教头子吗？🤣

我只是个路人，已点“Unsubscribe”，你可以继续认为自己“绝对正确”。

[Mq-b]

没有价值，你意识不到我的正确以及主张是你的损失，而不是我的。是我在为社区的发展以及新人的学习做出贡献，而不是你。

[frederick-vs-ja]

@zwhfly 至少这里不该出现“编译器自行”。这似乎暗示了编译器有额外的自由，但实际上标准完全指定了哪些实体需要被捕获。

[zwhfly]

没有价值，你意识不到我的正确以及主张是你的损失，而不是我的。是我在为社区的发展以及新人的学习做出贡献，而不是你。

假设这句话是对的，也不能让你说的话自动变成“绝对正确”。
同样，重复一万遍类似于“我说有问题就是有问题”的话毫无意义。

[zwhfly]

@zwhfly 至少这里不该出现“编译器自行”。这似乎暗示了编译器有额外的自由，但实际上标准完全指定了哪些实体需要被捕获。

“编译器自行”对应于“人工手动指定”啊。我觉得这样说没问题。

反过来讲，如果“编译器自行”暗示了可以违反标准的话，是否要在本书中删掉所有出现“编译器自行”的地方？

[frederick-vs-ja]

反过来讲，如果“编译器自行”暗示了可以违反标准的话，是否要在本书中删掉所有出现“编译器自行”的地方？

是的，说得好。这两行就是本书中所有出现“编译器自行”的地方。

[MrShinshi]

@zwhfly 至少这里不该出现“编译器自行”。这似乎暗示了编译器有额外的自由，但实际上标准完全指定了哪些实体需要被捕获。

“编译器自行”对应于“人工手动指定”啊。我觉得这样说没问题。

反过来讲，如果“编译器自行”暗示了可以违反标准的话，是否要在本书中删掉所有出现“编译器自行”的地方？

您好, 我只查到了唯一一处"编译器自行"就是我们正在讨论的这处, 如果您看到了别的使用"编译器自行"这种暧昧的表达我们可以一起审视下.

[zwhfly]

是的，说得好。这两行就是本书中所有出现“编译器自行”的地方。

您好, 我只查到了唯一一处"编译器自行"就是我们正在讨论的这处

哈哈，如果非要这样说，那“编译器自动”呢？

我的意思是“编译器自行”“编译器自动”这类说法是十分常见和正常的说法。不该看到“the compiler do xxx by itself”就觉得编译器可以违反标准了。

[Mq-b]

没有价值，你意识不到我的正确以及主张是你的损失，而不是我的。是我在为社区的发展以及新人的学习做出贡献，而不是你。

假设这句话是对的，也不能让你说的话自动变成“绝对正确”。 同样，重复一万遍类似于“我说有问题就是有问题”的话毫无意义。

你的话是最没有价值的，没有人愿意和你胡搅蛮缠，我说了我是对的，那是因为我知道我是对的，你的言论没有丝毫打动我，而我不想教导你什么，我只关注问题本身，认为这里需要修改，我没有义务教会你什么，我只需要阐述清晰的观点即可。是你非要转移话题引入别的地方，并为我扣了各种帽子：

吸引眼球的标题，然后绕个圈到4楼才说出你的真实想法

连写github issue都要标题党吗？

指出还不改。这是在浪费作者和关注者的时间。

好一个“绝对正确”。你是邪教头子吗？🤣

我只是个路人，已点“Unsubscribe”，你可以继续认为自己“绝对正确”。

• 然而不管如何都是无所谓的，这都不影响一个事实：我的正确。

还是那句话，

• 你意识不到我的正确以及主张是你的损失，而不是我的。是我在为社区的发展以及新人的学习做出贡献，而不是你。

[frederick-vs-ja]

是的，说得好。这两行就是本书中所有出现“编译器自行”的地方。

您好, 我只查到了唯一一处"编译器自行"就是我们正在讨论的这处

哈哈，如果非要这样说，那“编译器自动”呢？

我的意思是“编译器自行”“编译器自动”这类说法是十分常见和正常的说法。不该看到“the compiler do xxx by itself”就觉得编译器可以违反标准了。

“编译器自动”在本书中未出现，不适合在此讨论。如果你有什么争议，可以到别的 repo at 我一下。

另外，好的技术书籍最好能自己消除可能的误解。依赖没有在书中约定的“该”或“不该”并不是好事。