c# - 当可以在 lambda 中使用 await 时，为什么不能在 lambda 中使用 yield？

Question

According to Eric Lippert, anonymous iterators were not added to the language because it would be overly complicated to implement it.

这对我来说没问题，直到他们继续实现匿名异步方法后我才感到困扰。编译器必须为异步方法做同样的事情，因为它必须为迭代器做同样的事情(将它们转换为状态机)，所以我很困惑为什么匿名迭代器也不允许，而匿名异步方法是允许的。

有人可以阐明这一点吗？

Answer 1

According to Eric Lippert, anonymous iterators were not added to the language because it would be overly complicated to implement it.

这并不是我想要表达的。相关成本是实现成本，是的，但它是现有编译器中的实现成本，该编译器在架构上未设置为实现该复杂功能。

The compiler has to do the same thing for async methods as it has to for iterators (convert them into state machines), so I am very confused why anonymous iterators are not allowed as well, when anonymous async methods are.

简短的历史是相关的。 C# 在 C# 2.0 中首先具有匿名方法和迭代器 block 。当我在 C# 3.0 中添加 lambda 时，重构所有现有的匿名方法代码以使其能够处理 lambda 的所有新功能是一项重大成本。这使得修改变得更加复杂和昂贵。制作迭代器 block lambda 被认为对于应计 yield 来说成本太高；这将占总成本的很大一部分。 我们负担不起。如果把 Developer Division 的工作时间表中的每个团队都加起来，“最长杆”的团队是 C# 3.0 编译器团队，而我在语义分析器方面的工作是 IIRC编译器团队中最长的杆子。我们可能错过了 C# 3.0 的每一天，Visual Studio 也会错过这一天。因此，任何不能使 LINQ 变得更好的东西都被删除了，其中包括迭代器 lambda。

在 C# 4 中，迭代器 lambda 是被考虑的众多特性之一。我们有一个潜在的好功能列表，字面上比你的 ARM 还长，我们可以负担得起做不到其中的十分之一。

在 C# 5 中，团队添加了异步方法。设计和实现团队尝试了很长时间，以提出迭代器 block 和等待重写所共有的底层抽象；正如您所注意到的，它们显然相似。但最终，寻找通用解决方案的成本并没有收回成本。通用性非常昂贵，如果它不便宜，那么找到一个通过设计只统一两个事物的通用性是愚蠢的。

因此决定将 await 重写器作为自己的东西来实现。考虑到团队要承担这么大的成本，并且考虑到异步方法的原始转换无论如何都会变成 lambda 形式，因此决定投资于完整的功能:包含 lambda 的异步方法、异步 lambda包含 lambda，整个交易。该功能的成本只是整个功能成本的一小部分，非常昂贵。

再一次，我们遇到了长杆的问题。应避免在 lambda 引擎上进行任何可能破坏 await 稳定性的工作，包括尝试使它们与迭代器 block 一起工作。

现在比较 Visual Basic。 VB 很长一段时间根本没有迭代器 block 。添加它们时，没有现有的基础设施可以继续工作!整个事情可以从头开始构建，以处理包含 lambda 的迭代器 block 和包含迭代器 block 的 lambda，这样就完成了。

C# 编译器已通过 Roslyn 项目彻底重构和重写。我希望这将降低在假设的 future C# 版本中实现迭代器 block lambda 的成本。我们拭目以待!