C# 为什么存在async关键字

浏览第9频道msdn视频，我发现了以下未回复的评论，希望有人能解释一下

我不明白async关键字的意思。为什么不允许 wait关键字，只要方法返回任务，就像迭代器一样 可以在返回IEnumerable的任何方法上产生返回

---

我相信有一个很好的理由，我只是想理解为什么上面的建议不可行。

我想这篇文章可能涵盖了以下原因：

第一段指出：

很多人问我是什么促使设计决策 要求在任何包含“await”表达式的方法前加前缀 使用上下文关键字“async”

它的结论是：

这有很多优点和缺点；在对所有这些进行评估之后，以及 大量使用原型编译器来了解它的感觉， C#设计人员决定在一个 包含一个“等待”。我认为这是一个合理的选择

它的缺点是向后兼容

进一步阅读：

---

引入它主要是为了避免向后兼容性问题。如果编译器必须推断出方法的

async

-ness（这将通过检测

await

关键字来推断），那么存在一些微妙的情况，现有代码会突然被区别对待，特别是当您有标识符时（称为

await

的变量或函数名）

---

这里有一个完整的解释：

对我来说，最令人信服的原因是

return

语句的含义在函数变为

异步时发生变化。没有asnyc
asnyc
returnx
意味着“返回一个值为
x
的任务”，而使用async则意味着“将任务结果设置为
x
我不久前在博客上写了一篇文章

下面是“推断
async
”一节的结论：

埃里克·利珀特对此有自己的见解。在和中也有讨论

总而言之，单个单词
await
关键字将是一个太大的突破性更改。可以选择多单词await（例如，
await for
）或方法上的关键字（
async
）这将在该方法中启用
await
关键字。显式标记方法
async
对于人类和计算机来说都更容易解析，因此他们决定使用
async/await
对

我的蜘蛛感觉很刺痛……Jon Skeet就要来了！在我们等待的时候，再进一步阅读一下：需要两个关键字在不同的位置来实现一个新功能似乎是一个糟糕的设计选择。事实上，很多人问这个问题意味着（对我来说）这是一个错误的选择。通读博客中的所有推理，我可以遵循逻辑，但妥协并不总是最好的计划。有时最好打破一些代码继续前进。我个人认为做出了最安全的选择。如果打破代码和不打破代码之间的所有区别只是一个简单的关键字，那么这就是“这不是一项太繁重的任务。人们可能会直言不讳，但我们可以假设他们不会遇到向后兼容性问题。许多同意或公正的人都不会直言不讳。@Adelphus:那么，让我们使用科学吧。您创建了自己的实现，而不使用async关键字，我们将看到有多少问题会引发。s”建议用编译器选项和[EnableAwait（true | false）]属性替换它：+1。引用Eric Lippert是仅次于Eric Lippert的最佳选择：）我只想补充一点，我非常希望C#2设计人员决定使用“迭代器”或者在每个方法的开头添加一些类似的关键字，以作为迭代器。在知道它是否是迭代器块之前，必须解析整个方法体是非常麻烦的。更不用说它也允许匿名方法成为迭代器。Url是否断开？我认为这是指：