绝望的C#：Task是个良好的设计吗？

专栏介绍与文章目录-CSDN博客

        我对高级语言的异步机制总感到理解起来比较困难。明确的创建任务、等待任务不好吗？

        执行异步调用的方法返回一个Task是很正常的，很容易理解，但是Task.Result为什么导致阻塞呢？

        一个属性，而不是一个方法，竟然导致了阻塞，你们高级语言的思路真是很高级啊。

        好吧，这只是个吐槽。

        下面这个图来自微软learn网站，用来介绍异步方法的运行机制，非常大厂风啊：

        屁大点事画个图眼花缭乱。其实里面只有两个关键点：

1. client.GetStringAsync发起一个异步任务，一般我们（C/C++派）就称之为“CreateTask...”或者“StartTask...”，这一步不会阻塞。
2. await getStringTask等待异步任务结束，一般我们就是用个“Wait...”，这一步会阻塞，等待任务结束以便获得结果。

        为了在层层调用中发现是否存在等待而引入新的关键字是可以理解的，毕竟这样做有很大的好处（不然从层层调用里发现哪里阻塞是很头疼的）。

        但是Task的设计是很怪的。Task本身没什么不可理解的，但是Task.Result为什么会阻塞？这只是一个属性啊！检查任务结果和等待任务返回根本就是两个完全不相干的事情，怎么能混在一起呢？仅仅因为语法上支持？

（这里是结束）