探索 Rust 异步简化编程( 五 ) _Rust

async fn must_complete { ... }#[abort_safe]async fn can_abort { // Invalid call => compiler error must_complete;}async fn must_complete { ... }#[abort_safe]async fn can_abort { // Valid call spawn(async { must_complete }).join;}开发者可以通过生成新任务的方式，从非中止安全函数中获得中止安全的上下文。
异步语句的两个新变种会增加语言的复杂性，但这个复杂性仅在学习曲线的后期才出现。在刚开始学习Rust时，默认的异步语句是非中止安全的。从这个上下文中，学习者可以不用关心中止安全性而直接调用异步函数。中止安全会在异步Rust的教程的后期作为一个可选的话题出现。

文章插图

漫漫长路从目前的默认要求中止安全的异步模型改变成保证完成的模型，需要一个全新的Rust版本。处于讨论的目的，我们假设Rust 2026版引入了该变动。那么该版本中的Future trait将改变为保证完成的future，因此无法与老版本的trait兼容。相反，2026版中的旧trait将改名为AbortSafeFuture（名称暂定）。
在2026版中，给异步语句添加#[abort_safe]会生成一个AbortSafeFuture实现，而不是Future 。2026之前版本中编写的任何异步函数都实现了AbortSafeFuture trait，因此任何已有的异步代码都能与新版本兼容（别忘了，中止安全的函数可以从任何上下文中调用）。

一些想法我讨论了Rust可能出现的一些改动。简单地总结一下：

异步函数保证完成
去掉await关键字
引入#[abort_safe]标注，表示异步函数是中止安全的
限制select!，仅接受中止安全的分支
取消已生成的任务的方式是禁止资源完成
支持带有作用域的任务

我相信，这些改动可以极大地简化Rust异步，尽管进行这些改动会影响现状。在进行决定之前，我们还需要更多数据。如今的异步代码有多少是中止安全的？我们能否进行易用性研究，以评价这些改动的好处？Rust拥有两种风格的异步语句，会带来多少认知上的困难？
我也希望本文能抛砖引玉，期待其他人能提出别的观点。现在Rust需要许多观点来决定其未来。
原文链接：
https://carllerche.com/2021/06/17/six-ways-to-make-async-rust-easier/
声明：本文由CSDN翻译，转载请注明来源。

【探索 Rust 异步简化编程】