我认为写出其他语言如何处理await构造可能很有用。

科特林

val result = task.await()

C

var result = await task;

F

let! result = task()

斯卡拉

val result = Await.result(task, timeout)

蟒蛇

result = await task

的JavaScript

let result = await task;

C ++（协程TR）

auto result = co_await task;

哈克

$result = await task;

镖

var result = await task;

所有这些，让我们记住，Rust表达式可以产生几种链式方法。 大多数语言都不会这样做。

所有这些，让我们记住，Rust表达式可以产生几种链式方法。 大多数语言都不会这样做。

我会说支持扩展方法的语言倾向于拥有它们。 这些将包括Rust，Kotlin，C＃（例如，方法语法LINQ和各种生成器）和F＃，尽管后者大量使用管道运算符来达到相同的效果。

我的观点纯属轶事，但我经常在野外用Rust代码运行十几种方法链接的表达式，它读取并运行良好。 我没有在其他地方经历过。

我希望看到此问题在＃50547的最高帖子中得到了提及（在复选框“ await的最终语法”旁边）。

科特林

val result = task.await()

Kotlin的语法是：

val result = doTask()

await只是suspendable function ，不是一流的东西。

谢谢你提到那件事。 Kotlin感到更加隐含，因为默认情况下期货急切。 但是，在延迟块中使用该方法等待其他延迟块仍然是常见的模式。 我当然已经做过几次了。

@cramertj既然在https://github.com/rust-lang/rust/issues/50547中有276条评论，您可以总结一下其中所做的论点，以使其在此处不再重复吗？ （也许在这里将它们添加到OP中？）

Kotlin感到更加隐含，因为默认情况下期货急切。 但是，在延迟块中使用该方法等待其他延迟块仍然是常见的模式。 我当然已经做过几次了。

也许您应该在两个用例中添加一些上下文/描述。

还有其他使用隐式等待的langs，例如go-lang呢？

支持后缀语法的一个原因是，从调用者的角度来看，await的行为与函数调用非常相似：您放弃流控制，当您将其返回时，结果正在等待堆栈。 无论如何，我更喜欢通过包含函数形容词来包含类函数行为的语法。 并且有充分的理由想要将协程的构造与首次执行分开，以使此行为在同步块和异步块之间保持一致。

但是，尽管对隐式协程样式进行了辩论，而我站在显性立场，但.await!()或多或少是试图区分正常调用和协程调用之间的尝试。

因此，希望在对为何首选后缀提出了一些新的见解之后，提出了一个卑鄙的语法建议：

• future(?)
• 或future(await)当然具有其自身的权衡因素，但似乎不那么令人困惑，请参阅文章底部。

从其他线程改编一个相当受欢迎的示例（假设logger.log也是协程，以显示立即调用的外观）：

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.log("beginning service call")(?);
   let output = service(?); // Actually wait for its result
   self.logger.log("foo executed with result {}.", output)(?);
   output
}

并选择：

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.log("beginning service call")(await);
   let output = service(await);
   self.logger.log("foo executed with result {}.", output)(await);
   output
}

为避免代码不可读并有助于解析，请仅在问号后留空格，不要在问号和开放的paran之间留空格。 因此， future(? )很好，而future( ?)不好。 在future(await)的情况下不会出现此问题，在该情况下所有当前令牌都可以像以前一样使用。

与其他后缀运算符（例如当前的? -try）的交互也就像在函数调用中一样：

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = acquire_lock()(?);
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.log_into(message)(?)?;
    logger.timestamp()(?);
    Ok(length)
}

要么

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = acquire_lock()(await);
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.log_into(message)(await)?;
    logger.timestamp()(await);
    Ok(length)
}

喜欢这个的一些理由：

• 与.await!()相比，它并不暗示可能具有其他用途的成员。
• 它遵循呼叫的自然优先级，例如链接和? 。 这样可以减少高级班的数量，并有助于学习。 而且函数调用在该语言中一直很特殊（即使具有某种特质），因此不会期望用户代码能够定义自己的语法和效果非常相似的my_await!() 。
• 这可以推广到生成器和流，以及期望在恢复时提供更多参数的生成器。 本质上，这表现为FnOnce而Streams表现为FnMut 。 附加的参数也很容易容纳。
• 对于那些谁使用当前Futures之前，该如何捕获一个?与Poll应该（在此不幸的稳定序列）所有的工作一起。 作为学习步骤，这也与期望基于?的运算符转移控制流相一致。 另一方面， (await)不能满足此要求，但毕竟该功能总是希望在发散点处恢复。
• 它确实使用类似函数的语法，尽管仅当您同意我的意见时，此参数才有用：：mile：

和不喜欢的原因：

• ?似乎是一个参数，但它甚至不应用于表达式。 我相信这可以通过教学解决，因为它似乎应用到的标记是函数调用本身，这在某种程度上是正确的概念。 我希望这也肯定地意味着语法是明确的。
• 括号和?更多（和不同）组合可能很难解析。 特别是当您有一个未来返回另一个未来的结果时： construct_future()(?)?(?)? 。 但是您可以为能够得到fn对象的结果做出相同的论点，从而导致这样的表达式： foobar()?()?()? 。 但是，由于我从未见过这种用法或抱怨，因此在这种情况下分割成单独的语句似乎很少需要。 construct_future()(await)?(await)?也不存在此问题-
• future(?)是我的最佳选择，语法仍然很简洁。 但是，其推理基于协同程序中的实现细节（临时返回并在简历上分派），这可能使其不适合抽象。 future(await)将是一个替代方案，在将await作为关键字内部化之后，仍然可以解释，但是参数位置对我来说有点难以接受。 可能很好，并且当协程返回结果时，它当然更具可读性。
• 是否干扰其他函数调用建议？
• 你自己？ 您不需要喜欢它，只是至少不提出这种简短的后缀语法感觉很浪费。

future(?)

Result没什么特别的：期货可以返回任何Rust类型。 碰巧有些期货返回Result

那么，对于不返回Result期货，它将如何工作？

似乎不清楚我的意思。 future(?)是先前讨论的future.await!()或类似内容。 将来也返回结果的分支将是future(?)? （我们可以尽早放弃控制流的两种不同方式）。 这使得将来轮询(?)和结果测试?正交。 编辑：为此添加了一个额外的示例。

在也返回结果的Future上分支将是future(?)?

感谢您的澄清。 在那种情况下，我绝对不喜欢它。

这意味着调用返回Future<Output = Result<_, _>>的函数将类似于foo()(?)?

这是非常繁重的语法，它使用?来实现两个完全不同的目的。

如果它特别是给运算符?的提示，那么当然可以用新保留的关键字替换它。 我只是在最初才认为这感觉太像是一个令人费解的实际争论，但是这种权衡可以帮助精神分析语句。 因此，相同的impl Future<Output = Result<_,_>>语句将变为：

• foo()(await)?

为什么?合适的最好论据是所使用的内部机制有些相似（否则我们不能在当前库中使用Poll ），但这可能会错过成为一个好的抽象的意义。

语法非常繁重

我认为这就是明确等待的全部内容吗？

它用 ？ 用于两个完全不同的目的。

是的，所以foo()(await) -syntax会好很多。

这种语法就像调用返回闭包的函数，然后在JS中调用该闭包一样。

我对“语法繁重”的阅读更接近于“语法沉重”，看到()(?)?的序列非常令人讨厌。 这是在原始帖子中提到的：

括号和?更多（和不同）组合可能很难解析。 尤其是当您有一个未来返回另一个未来的结果时： construct_future()(?)?(?)?

但是您可以为能够得到fn对象的结果做出相同的论点，从而导致这样的表达式： foobar()?()?()? 。 但是，由于我从未见过这种用法或抱怨，因此在这种情况下分割成单独的语句似乎很少需要。

我认为这里的反驳是：您在野外看到-> impl Fn了几次（更不用说-> Result<impl Fn() -> Result<impl Fn() -> Result<_, _>, _>, _> ）？ 您希望在异步代码库中看到-> impl Future<Output = Result<_, _>>多少次？ 必须命名一个罕见的impl Fn返回值以使代码更易于阅读与必须命名一个很大的临时impl Future返回值有很大的不同。

必须命名一个罕见的impl Fn返回值以使代码更易于阅读与必须命名一个很大的临时impl Future返回值有很大的不同。

我看不到这种语法选择如何影响必须显式命名结果类型的次数。 我认为与await? future相比，它不会影响类型推断。

但是，你们在这里都提出了非常好的观点，并且我尝试了更多的示例（我编辑了原始文章以始终包含两个语法版本），我自己也更倾向于future(await) 。 键入不是没有道理的，并且仍然保留了本应引起的所有函数调用语法的清晰度。

您希望看到多少次->暗示未来

>在异步代码库中？

我希望能一直看到与之等效的类型（返回结果的异步fn），甚至可能是所有异步fn中的大多数，因为如果您正在等待的甚至是IO，则几乎肯定会抛出IO错误向上。

链接到我先前关于跟踪问题的文章，并添加了更多想法。

我认为不包含字符串await语法接受这种语法的可能性很小。 我认为，在为此功能工作了一年之后，尝试权衡已知可行替代方案的优缺点，以找出最佳方案比提出新语法要好得多。 考虑到我以前的帖子，我认为语法是可行的：

• 前缀带有强制定界符。 这也是什么定界符（括号或括号或接受两者；所有这些都有其优缺点）的决定。 即await(future)或await { future } 。 这完全解决了优先权问题，但是在语法上比较嘈杂，并且两个定界符选项都可能引起混淆。
• 前缀以?的“有用”优先级等待。 （也就是说，等待绑定比？更紧密）。 这可能会使某些用户阅读代码感到惊讶，但是我认为返回结果期货的功能将比返回期货结果的功能更为普遍。
• 前缀以?的“明显”优先级等待。 （也就是说，绑定比等待绑定更紧密）。 额外的语法糖await?用于等待和？ 操作员。 我认为必须使用这种语法糖才能使该优先顺序完全可行，否则每个人都会一直在写(await future)? ，这是我列举的第一个选项的较差变体。
• 使用语法空间等待Postfix。 这通过在两个运算符之间具有清晰的视觉顺序来解决优先级问题。 在很多方面，我对此解决方案感到不安。

每次检查问题时，我对这些选择的排名都会改变。 到目前为止，我认为在糖上使用明显的优先级似乎是人体工程学，熟悉程度和理解力之间的最佳平衡。 但是在过去，我偏爱其他两种前缀语法中的任何一种。

为了便于讨论，我将为这四个选项命名：

姓名| 未来| 结果的未来| 未来的结果
--- | --- | --- | ---
强制分隔符| await(future)或await { future } | await(future)?或await { future }? | await(future?)或await { future? }
有用的优先级| await future | await future? | await (future?)
带糖的明显优先级| await future | await? future或(await future)? | await future?
后缀关键字| future await | future await? | future? await

（我专门使用“ postfix关键字”将该选项与“ postfix宏”之类的其他postfix语法区分开。）

在“有用”优先级中“祝福” await future?的缺点之一，还有其他不能作为后缀起作用的缺点，是通常不再使用?手动转换表达式的模式，或要求Future以兼容方式显式复制Result方法。 我觉得这很奇怪。 如果它们被复制，那么哪个合并者在返回的未来上工作以及哪个渴望就变得令人困惑。 换句话说，与隐式等待的情况一样，决定组合器实际执行的操作也很困难。 （编辑：实际上，请参见下面的两个评论，其中我具有更技术性的观点，令人惊讶地替换?意味着什么）

我们可以从错误情况中恢复的示例：

async fn previously() -> Result<_, lib::Error> {
    let _ = await get_result()?;
}

async fn with_recovery() -> Result<_, lib::Error> {
    // Does `or_recover` return a future or not? Suddenly very important but not visible.
    let _ = await get_result().unwrap_or_else(or_recover);
    // If `or_recover` is sync, this should still work as a pattern of replacing `?` imho.
    // But we also want `or_recover` returning a future to work, as a combinator for futures?

    // Resolving sync like this just feel like wrong precedence in a number of ways
    // Also, conflicts with `Result of future` depending on choice.
    let _ = await get_result()?.unwrap_or_else(or_recover);
}

实际的后缀运算符不会发生此问题：

async fn with_recovery() -> Result<_, lib::Error> {
    // Also possible in 'space' delimited post-fix await route, but slightly less clear
    let _ = get_result()(await)
        // Ah, this is sync
        .unwrap_or_else(or_recover);
    // This would be future combinator.
    // let _ = get_result().unwrap_or_else(or_recover)(await);
}

// Obvious precedence syntax
let _ = await get_result().unwrap_or_else(or_recover);

// Post-fix function argument-like syntax
let _ = get_result()(await).unwrap_or_else(or_recover);

这些是不同的表达式，点运算符的优先级高于“明显优先级”的await运算符，因此等效项是：

let _ = get_result().unwrap_or_else(or_recover)(await);

这与or_recover是否异步完全相同。 （我认为这并不重要，您知道整个表达式是异步的，如果出于某种原因需要知道特定部分是否异步，则可以查看or_recover的定义）。

这与or_recover是否异步完全相同。

不完全一样。 unwrap_or_else必须产生协程，因为它已经被等待，因此歧义是get_result是协程（因此构建了一个组合器）还是Result<impl Future, _> （和Ok已经包含一个协程，并且Err构建一个）。 这两个人没有相同的担忧，即能够通过将await序列点移至join来一目了然地识别效率增益，这是该公司的主要担忧之一隐式等待。 原因是在任何情况下，此中间计算都必须是同步的，并且必须在等待之前已应用于该类型，并且必须已导致等待协程。 这里还有一个更大的问题：

这些是不同的表达式，点运算符的优先级高于“显而易见的优先级” await运算符，因此等效项是

这就是混乱的一部分，用恢复操作替换? await根本上改变了?语法的上下文中，给定类型T的部分表达式expr T ，我希望转换中具有以下语义（假设T::unwrap_or_else存在） ：

• expr? -> expr.unwrap_or_else(or_recover)
• <T as Try>::into_result(expr)? -> T::unwrap_or_else(expr, or_recover)

但是，在“有用优先级”和await expr? （ await expr产生T ）下，我们得到

• await expr? -> await expr.unwrap_or_else(or_recover)
• <T as Try>::into-result(await expr) -> await Future::unwrap_or_else(expr, or_recover)

而在明显的先例中，这种转换在没有额外的寄生的情况下根本不再适用，但是至少直觉仍然适用于“未来的结果”。

在更有趣的情况下，您在组合器序列中的两个不同点处等待呢？ 我认为，使用任何前缀语法，都需要使用括号。 Rust的其余语言都竭尽全力避免这种情况，以使“表达式从左到右进行评估”，其中一个示例是自动引用魔术。

示例显示，对于具有多个等待/尝试/组合点的较长链，情况会变得更糟。

// Chain such that we
// 1. Create a future computing some partial result
// 2. wait for a result 
// 3. then recover to a new future in case of error, 
// 4. then try its awaited result. 
async fn await_chain() -> Result<usize, Error> {
    // Mandatory delimiters
    let _ = await(await(partial_computation()).unwrap_or_else(or_recover))?
    // Useful precedence requires paranthesis nesting afterall
    let _ = await { await partial_computation() }.unwrap_or_else(or_recover)?;
    // Obivious precendence may do slightly better, but I think confusing left-right-jumps after all.
    let _ = await? (await partial_computation()).unwrap_or_else(or_recover);
    // Post-fix
    let _ = partial_computation()(await).unwrap_or_else(or_recover)(await)?;
}

我希望避免出现的情况是，创建C的类型解析的Rust模拟，在您之间跳转
“指针”和“数组”组合器的表达式的左侧和右侧。

@withoutboats样式的表项：

| 姓名| 未来| 结果的未来| 未来的结果
|-|-|-|-||
| 强制分隔符| await(future) | await(future)? | await(future?) |
| 有用的优先级| await future | await future? | await (future?) |
| 优先顺序| await future | await? future | await future? |
| 后缀通话| future(await) | future(await)? | future?(await) |

| 姓名| 链式|
|-|-|
| 强制分隔符| await(await(foo())?.bar())? |
| 有用的优先级| await(await foo()?).bar()? |
| 优先顺序| await? (await? foo()).bar() |
| 后缀通话| foo()(await)?.bar()(await) |

由于各种原因，我强烈赞成等待postfix，但我不喜欢@withoutboats所示的变体，主要是出于相同的原因。 例如。 foo await.method()令人困惑。

首先让我们看一个类似的表，但是添加几个其他的postfix变体：

| 姓名| 未来| 结果的未来| 未来的结果
| ---------------------- | -------------------- | ----- ---------------- | --------------------- |
| 强制分隔符| await { future } | await { future }? | await { future? } |
| 有用的优先级| await future | await future? | await (future?) |
| 优先顺序| await future | await? future | await future? |
| 后缀关键字| future await | future await? | future? await |
| 后缀字段| future.await | future.await? | future?.await |
| 后缀方法| future.await() | future.await()? | future?.await() |

现在，让我们看一下连锁的未来表达：

| 姓名| 结果链式期货|
| ---------------------- | -------------------------- ----------- |
| 强制分隔符| await { await { foo() }?.bar() }? |
| 有用的优先级| await (await foo()?).bar()? |
| 优先顺序| await? (await? foo()).bar() |
| 后缀关键字| foo() await?.bar() await? |
| 后缀字段| foo().await?.bar().await? |
| 后缀方法| foo().await()?.bar().await()? |

现在以一个真实示例为例，从reqwests ，在该位置您可能要等待链式的未来结果（使用我首选的await表单）。

let res: MyResponse = client.get("https://my_api").send().await?.json().await?;

实际上，我认为每个分隔符都适合后缀语法，例如：
let res: MyResponse = client.get("https://my_api").send()/await?.json()/await?;
但是我对使用哪个没有很强的看法。

后缀宏（例如future.await!() ）仍然可以选择吗？ 清楚，简洁和明确：

| 未来| 结果的未来| 未来的结果
| --- | --- | --- |
| future.await！（）| future.await！（）？ | 未来？.await！（）|

另外，postfix宏需要较少的精力来实现，并且易于理解和使用。

另外，postfix宏需要较少的精力来实现，并且易于理解和使用。

而且它只是使用一个通用的lang功能（或者至少看起来像一个普通的postfix宏）。

postfix宏会很好，因为它结合了postfix的简洁性和可链接性以及非魔术属性和宏的明显存在，并且非常适合第三方用户宏，例如某些.await_debug!() ， .await_log!(WARN)或.await_trace!()

postfix宏会很不错，因为它结合了宏的非魔术属性

@novacrazy这个参数的问题是任何await!宏_would_都是魔术，它执行的操作在用户编写的代码中是不可能的（当前基于底层生成器的实现有些公开，但是我的理解是，在稳定之前，此功能将完全隐藏（并且实际上与之交互目前需要使用一些rustc -反正内部夜间功能）。

@ Nemo157嗯。 我不知道它原本是如此的不透明。

重新考虑使用#[async]类的过程宏来进行从“异步”功能到生成器功能而不是魔术关键字的转换是否为时已晚？ 它是要键入的三个额外字符，可以在文档中以#[must_use]或#[repr(C)]相同的方式进行标记。

我真的不喜欢隐藏这么多直接控制执行流程的抽象层的想法。 感觉与Rust是对立的。 用户应该能够完全跟踪代码并弄清楚一切工作原理以及执行的位置。 应该鼓励他们擅自闯入并欺骗系统，如果他们使用安全的Rust，那就应该是安全的。 如果我们失去低水平的控制权，这并没有改善任何事情，我也最好坚持使用原始期货。

我坚信Rust（不是std / core ）的语言，仅在用户（或极不切实际）或std无法做到的情况下，才应提供抽象和语法。 。 在这方面，整个异步事情已经失控了。 除了rustc的pin API和生成器，我们真的需要更多东西吗？

@novacrazy我通常同意这种观点，但不同意结论。

仅当用户或std无法（或高度不切实际）执行抽象和语法时，才应提供抽象和语法。

语言中有for -loops的原因是什么，因为它们也可能是变成带有中断的loop的宏。 || closure可能是专用特征和对象构造函数的原因是什么？ 为什么我们已经有try!()时引入? try!() 。 我不同意这些问题和您的结论的原因是一致性。 这些抽象的重点不仅在于它们封装的行为，还在于其可访问性。 for -replacement在可变性，主代码路径和可读性方面发生了故障。 || -replacement在声明的详细程度上有所下降，类似于当前的Futures 。 try!()按预期的表达式和可组合性顺序分解。

考虑到async不仅是函数的装饰器，还考虑了通过aync-blocks和async ||提供其他模式的想法。 由于它适用于不同的语言项目，因此宏的可用性似乎不是最佳的。 如果它必须是用户可见的，那就不用考虑实现了。

用户应该能够完全跟踪代码并弄清楚一切工作原理以及执行的位置。 应该鼓励他们擅自闯入并欺骗系统，如果他们使用安全的Rust，那就应该是安全的。

我认为这种说法不适用，因为完全使用std api实现协程可能会严重依赖unsafe 。 然后有一个相反的论点，因为尽管它是可行的，并且即使语言有句法和语义的方式，您也不会停下来，但是任何更改都将有极大的可能打破用unsafe假设的风险。 extern "rust-call" ，它是当前的魔术，它清楚地表明函数调用没有任何这种保证。 我们可能想实际上从未有return ，即使stackful协程的命运还没有到决定。 我们可能想将优化挂接到编译器中。

旁白：说到这，从理论上讲，还不如完全严肃的想法，可以协同程序的await被表示为假想extern "await-call" fn () -> T ？ 如果是这样，这将在序言中

trait std::ops::Co<T> {
    extern "rust-await" fn await(self) -> T;
}

impl<T> Co<T> for Future<Output=T> { }

又名 future.await()在用户空间记录的项目中。 或就此而言，其他运算符语法也是可能的。

@HeroicKatora

为什么我们已经有try!()时引入? try!()

公平地说，我也反对这一观点，尽管它已经在我身上发展了。 如果Try曾经稳定过，那会更容易接受，但这是另一个话题。

您给出的“糖”示例的问题在于它们是非常非常稀薄的糖。 即使impl MyStruct是多了还是少糖为impl <anonymous trait> for MyStruct 。 这些是生活用糖，可以增加零开销。

相比之下，生成器和异步函数会增加很多无关紧要的开销和大量的精神开销。 特别地，生成器很难以用户的身份实现，并且可以更有效，更轻松地用作语言本身的一部分，而异步可以在此之上轻松实现。

不过，关于异步块或闭包的观点很有趣，我承认关键字在那里会更有用，但我仍然反对在必要时无法访问较低级别的项目。

理想情况下，支持async关键字和#[async]属性/过程宏将是很棒的选择，前者允许对生成的（无双关）生成器进行低级访问。 同时yield应在使用块或功能被禁止async作为关键字。 我确信他们甚至可以共享实现代码。

至于await ，如果两个以上是可能的，我们可以做同样的事情，并限制关键字await至async关键字功能/块，并使用某种await!() #[async]函数中的await!()宏。

伪代码：

// imaginary generator syntax stolen from JavaScript
fn* my_generator() -> T {
    yield some_value;

    // explicit return statements are only included to 
    // make it clear the generator/async functions are finished.
    return another_value;
}

// `await` keyword would not be allowed here, but the `yield` keyword is
#[async]
fn* my_async_generator() -> Result<T, E> {
    let item = some_op().await!()?; // uses the `.await!()` macro
    // which would really just use `yield` internally, but with the pinning API

    yield future::ok(item.clone());

    return Ok(item);
}

// `yield` would not be allowed here, but the `await` keyword is.
async fn regular_async() -> Result<T, E> {
   let some_op = async || { /*...*/ };

   let item = some_op() await?;

   return Ok(item);
}

两全其美。

这感觉就像是自然呈现给用户的复杂程度，可以更有效地用于更多应用。

请记住，此问题专门用于讨论await的语法。 关于如何实现async功能和块的其他讨论不在范围之内，除非是为了提醒人们await!不是您可以或将无法在Rust的书中写的东西。表面语言。

我想特别权衡所有修复后语法建议的优缺点。 如果其中一种语法与众不同，那么我们也许应该这样做。 但是，如果没有，最好是支持语法前缀定界的语法，如果需要的话，该语法可以与尚未确定的后缀向前兼容。 由于Postfix对于一些成员而言最为简洁，因此，在迁移到其他成员之前先对其进行强烈评估似乎是可行的。

比较将是syntax ， example （来自@mehcode的reqwest看起来像是在这方面可用的真实基准），然后是表格（ concerns和可选的resolution ，例如，如果同意可以归结为教学）。 随时添加语法和/或关注点，我将它们编辑到此汇总文章中。 据我了解，任何不涉及await语法都会对新手和有经验的用户产生异样的感觉，但是当前列出的所有语法都包括它。

一种前缀语法中的示例仅供参考，请不要踩踏此部分：

let sent = (await client.get("https://my_api").send())?;
let res: MyResponse = (await sent.json())?;

• Postfix关键字foo() await?
  
  
  
  • 示例： client.get("https://my_api").send() await?.json() await?
  
  
  • | 关注| 分辨率|
    
    |-|-|
    
    | 没有?可能会造成混乱或被禁止| |
  
  
• 后缀字段foo().await?
  
  
  
  • 示例： client.get("https://my_api").send().await?.json().await?
  
  
  • | 关注| 分辨率|
    
    |-|-|
    
    | 看起来像田野 |
  
  
• 后缀方法foo().await()?
  
  
  
  • 示例： client.get("https://my_api").send().await()?.json().await()?
  
  
  • | 关注| 分辨率|
    
    |-|-|
    
    | 看起来像方法或特征| 它可能被记录为ops::特性？ |
    
    | 不是函数调用 |
  
  
• 后缀通话foo()(await)?
  
  
  
  • 示例： client.get("https://my_api").send()(await)?.json()(await)?
  
  
  • | 关注| 分辨率|
    
    |-|-|
    
    | 可以与实际参数混淆关键字+突出显示+不重叠|
  
  
• Postfix宏foo().await!()?
  
  
  
  • 示例： client.get("https://my_api").send().await!()?.json().await!()?
  
  
  • | 关注| 分辨率|
    
    |-|-|
    
    | 实际上不会是宏……| |
    
    | …或await不再是关键字| |
  
  

从可能合并生成器的角度出发，对后缀与前缀的另一种思考：考虑值， yield和await占据两种相反的语句。 前者从您的函数到外部提供一个值，后者接受一个值。

旁注：好吧，Python有交互式生成器，其中yield可以返回一个值。 对称地，在强类型设置中，对此类生成器或流的调用需要其他参数。 让我们不要过于概括，我们将看到在两种情况下该参数都可能转移。

然后，我认为应该使这些陈述看起来相似是很自然的。 在这里，与赋值表达式类似，当该规范对于Rust而言不太一致且不太简洁时，也许我们应该偏离其他语言制定的规范。 如在其他地方表示的那样，只要我们包含await并且与具有相同参数顺序的其他表达式存在相似性，即使从另一个模型进行转换也应该没有主要障碍。

由于隐式似乎不在桌面上。

通过使用其他语言的async / await并查看此处的选项，我从未发现链期货在语法上令人愉悦。

桌子上是否有非连锁型？

// TODO: Better variable names.
await response = client.get("https://my_api").send();
await response = response?.json();
await response = response?;

我有点像这样，因为您可以说它是模式的一部分。

与等待绑定有关的问题是错误的故事不太好。

// Error comes _after_ future is awaited
let await res = client.get("http://my_api").send()?;

// Ok
let await res = client.get("http://my_api").send();
let res = res?;

我们需要牢记，社区中几乎所有可供等待的期货都是有问题的，必须与?结合使用。

如果我们真的需要语法糖：

await? response = client.get("https://my_api").send();
await? response = response.json();

await和await?都需要作为关键字添加，或者我们也将其扩展到let ，即let? result = 1.divide(0);

考虑到Rust代码中使用链接的频率，我完全同意，对于链接的等待者来说，尽可能清晰地了解链接很重要。 对于await的postfix变体：

client.get("https://my_api").send().await()?.json().await()?;

这通常与我期望Rust代码的行为类似。 我确实有一个问题，在这种情况下await()感觉就像一个函数调用，但是在表达式的上下文中具有神奇的（非函数类）行为。

后缀宏版本将使这一点更加清晰。 人们习惯了锈蚀感叹号，意思是“这里有魔术”，因此我当然更喜欢此版本。

client.get("https://my_api").send().await!()?.json().await!()?;

话虽如此，值得考虑的是，我们已经有try!(expr)的语言，并且它是?前身。 添加一个await!(expr)现在的宏将与如何完全一致try!(expr)和?被引入的语言。

使用await!(expr)版本的await，我们可以选择稍后迁移到postfix宏，或者添加新的?样式运算符，以使链接变得容易。 一个类似于?的示例，但等待：

// Not proposing this syntax at the moment. Just an example.
let a = perform()^;

client.get("https://my_api").send()^?.json()^?;

我认为我们现在应该使用await!(expr)或await!{expr} ，因为它既合理又实用。 然后，我们可以计划在是否将一次postfix宏变成一个东西之后，再迁移到await的postfix版本（即.await!或.await!() ）。 （或者最终在增加了关于主题的问题之后，添加了一个额外的?样式运算符...的路线：）

仅供参考，Scala的语法不是Await.result因为这是一个阻塞调用。 Scala的Futures是monad，因此使用常规方法调用或for monad理解：

for {
  result <- future.map(further_computation)
  a = result * 2
  _ <- future_fn2(result)
} yield 123

由于这种可怕的表示法，使用我最赞成的语法创建了一个名为scala-async的库，如下所示：

import scala.concurrent.ExecutionContext.Implicits.global
import scala.async.Async.{async, await}

val future = async {
  val f1 = async { ...; true }
  val f2 = async { ...; 42 }
  if (await(f1)) await(f2) else 0
}

这强烈反映了我希望rust代码的样子，并使用了强制定界符，因此，我想与其他人保持一致，以保持当前语法await!() 。 我认为，早期的Rust是沉重的象征，并且出于充分的理由而被移开了。 和往后一样，以后缀运算符（或您所拥有的形式）形式使用语法糖是向后兼容的，并且await!(future)的清晰度是明确的。 如前所述，它也反映了我们使用try!的进度。

将其保留为宏的好处是，一眼就可以看出它是语言功能，而不是普通的函数调用。 如果不添加! ，则突出显示编辑器/查看器的语法将是发现调用的最佳方法，我认为依赖这些实现是一个较弱的选择。

我的两分钱（不是定期供款人，fwiw）我最喜欢复制try! 。 它曾经做过一次，并且运行良好，并且在它变得非常流行之后，有足够的用户考虑使用后缀运算符。

所以我的投票是：用await!(...)稳定，然后在一个postfix运算符上平移，以基于Rust开发人员的调查得出很好的链接。 Await是一个关键字，但是!表示对我来说这是“神奇”的事情，并且括号中的内容清晰易懂。

也是一个比较：

| 后缀| 表达|
| --- | --- |
| .await | client.get("https://my_api").send().await?.json().await? |
| .await! | client.get("https://my_api").send().await!?.json().await!? |
| .await() | client.get("https://my_api").send().await()?.json().await()? |
| ^ | client.get("https://my_api").send()^?.json()^? |
| # | client.get("https://my_api").send()#?.json()#? |
| @ | client.get("https://my_api").send()@?.json()@? |
| $ | client.get("https://my_api").send()$?.json()$? |

我的第三分是我喜欢@ （代表“等待”）和# （代表多线程/并发）。

我也喜欢后缀@ ！ 我认为这实际上不是一个坏选择，即使似乎有人认为它不可行。

• _ @ for await_是一个很好且易于记忆的助记符
• ?和@非常相似，因此在学习@之后学习?不应该是一个飞跃
• 它有助于从左到右扫描一连串的表达式，而不必向前扫描以找到一个结束定界符以了解一个表达式

我非常赞成await? foo语法，并且我认为它类似于在数学中看到的某些语法，例如。 sin²x可以用来表示（sin x）²。 起初看起来有些尴尬，但是我认为这很容易适应。

如上所述，我很乐意添加await!()作为宏，就像try!() ，现在并最终决定如何对其进行后缀处理。 如果我们可以牢记支持将自动将await!()调用转换为后缀等待的rustfix，这还有待确定，甚至更好。

postfix关键字选项对我来说显然是赢家。

• 没有优先级/顺序问题，但是仍然可以使用括号使顺序明确。 但是大多数情况下不需要过多的嵌套（类似的参数，希望使用后缀'？'代替'try（）！'）。

• 多行链接看起来不错（请参阅@earthengine的先前评论），再次，关于订购或正在等待的东西没有混淆。 对于多次使用await的表达式，没有嵌套/额外的括号：

let x = x.do_something() await
         .do_another_thing() await;
let x = x.foo(|| ...)
         .bar(|| ...)
         .baz() await;

• 它适合于一个简单的await！（）宏（请参阅@novacrazy的早期注释）：

macro_rules! await {
    ($e:expr) => {{$e await}}
}

• 即使是单行的，裸露的（不带“？”），postfix await关键字链接也不会打扰我，因为它从左到右读取，并且我们正在等待返回值，然后后续方法对其进行操作（尽管我只会更喜欢多行rustfmt'ed代码）。 该空间使行断裂，并且足以等待正在发生的视觉指示器/提示：

client.get("https://my_api").send() await.unwrap().json() await.unwrap()

为了建议另一个我尚未见过的候选人（也许因为它无法解析），有趣的双点'..'后缀运算符怎么办？ 它使我想起我们正在等待某些东西（结果！）...

client.get("https://my_api").send()..?.json()..?

我也喜欢后缀@ ！ 我认为这实际上不是一个坏选择，即使似乎有人认为它不可行。

• _ @ for await_是一个很好且易于记忆的助记符
• ?和@非常相似，因此在学习@之后学习?不应该是一个飞跃
• 它有助于从左到右扫描一连串的表达式，而不必向前扫描以找到一个结束定界符以了解一个表达式

我不喜欢使用@等待。 在fin / swe布局键盘上键入很麻烦，因为我必须用右手拇指按下alt-gr，然后在数字行上按下键2。 另外，@的含义很明确（at），所以我不明白为什么要混淆它的含义。

我宁愿只键入await ，它会更快，因为它不需要任何键盘杂技。

这是我自己的非常主观的评估。 我还添加了future@await ，这对我来说似乎很有趣。

| 语法| 笔记|
| --- | --- |
| await { f } | 强大：

• 非常简单
• 平行for ， loop ， async等。

• 非常冗长（5个字母，2个大括号，3个可选的，但可能是倾斜的空格）
• 链接会产生许多嵌套的括号（ await { await { foo() }?.bar() }? ）

• 从Python，JS，C＃和Dart并行await语法
• 简单，简短
• 有用的优先级和明显的优先级在? （ await fut? vs. await? fut ）中表现良好

• 模棱两可：必须学习有用与明显的优先顺序
• 链接也很麻烦（ await (await foo()?).bar()? vs. await? (await? foo()).bar() ）

• 允许非常容易的链接
• 短
• 很好的代码完成

• 愚弄用户以为这是在某个地方定义的字段/功能/宏。 编辑：我同意@jplatte await!()觉得最神奇

• 允许非常容易的链接
• 短

• 愚弄用户以为在某个地方定义了await变量，并且可以像函数一样调用Future

• 允许非常容易的链接
• 短

• 在Rust的语法中几乎没有任何相似之处，不明显
• 我的大脑将client.get("https://my_api").send() await.unwrap().json() await.unwrap()分为client.get("https://my_api").send() ， await.unwrap().json()和await.unwrap() （首先按分组，然后按.分组）这是不正确的
• 对于Haskellers：看起来像是在招惹，但不是

• 允许非常容易的链接
• 很短

• 看起来有点尴尬（至少起初）
• 消耗@可能更适合其他东西
• 可能容易被忽略，尤其是在大表达式中
• 与所有其他语言使用@的方式不同

• 允许非常容易的链接
• 短
• 很好的代码完成
• await不必成为关键字
• forwards-compatible：允许以@operator的形式添加新的postfix运算符。 例如， ?可以作为@try 。
• 我的大脑将client.get("https://my_api").send()@await.unwrap().json()@await.unwrap()分组为正确的组（首先按.分组，然后按@分组）

• 与所有其他语言使用@的方式不同
• 可能会增加太多不必要的后缀运算符

我的分数：

• 熟悉程度（fam）：此语法与已知语法（Rust和其他语法，例如Python，JS，C＃）的距离有多近
• 明显性（obv）：如果您是第一次使用别人的代码阅读此书，您是否可以猜测其含义，优先顺序等？
• 详细程度（vrb）：要写多少个字符
• 可见性（可见性）：在代码中发现（相对于忽略）有多么容易
• chaining（cha）：与.和其他await s链接起来很容易
• 分组（grp）：我的大脑是否将代码分组为正确的块
• forwards-compatibility（fwd）：是否允许以后以不间断的方式进行调整

| 语法| 家族| obv | vrb | 可见| 茶| grp | fwd |
| --------------------- | ----- | ----- | ----- | ----- | --- -| ----- | ----- |
| await!(fut) | ++ | + | -| ++ | -| 0 | ++ |
| await { fut } | ++ | ++ | -| ++ | -| 0 | + |
| await fut | ++ | -| + | ++ | -| 0 | -|
| fut.await | 0 | -| + | ++ | ++ | + | -|
| fut.await() | 0 | -| -| ++ | ++ | + | -|
| fut.await!() | 0 | 0 | -| ++ | ++ | + | -|
| fut(await) | -| -| 0 | ++ | ++ | + | -|
| fut await | -| -| + | ++ | ++ | -| -|
| fut@ | -| -| ++ | -| ++ | ++ | -|
| fut@await | -| 0 | + | ++ | ++ | ++ | 0 |

在我看来，确实像我们应该在第一个剪切中镜像try!()语法，并在引入其他语法之前从使用await!(expr)获得一些实际用法。

但是，如果/何时构造另一种语法。

我认为@看起来很难看，“ at”代表“异步”对我来说并不直观，并且该符号已经用于模式匹配。

不带括号的async前缀与? （通常会使用）一起使用时，会导致不明显的优先级或周围的括号。

Postfix .await!()很好地链接了一下，其含义立刻就很明显了，其中包括!来告诉我它会去做魔术，并且在语法上不太新颖，因此采用“下一个剪切”方法个人会喜欢这个。 就是说，对我来说，与第一次削减await! (expr) ，它将改善实际代码多少还有待观察。

对于简单情况，我更喜欢使用前缀运算符：
let result = await task;
考虑到我们不写结果的类型，这感觉更自然，因此从左到右阅读以了解结果是等待任务时，await在精神上会有所帮助。
像这样想象：
let result = somehowkindoflongtask await;
直到您未完成任务的末尾，您才意识到必须等待它返回的类型。 还请记住（尽管这可能会发生变化，并且不会直接与语言的未来联系在一起），作为Intellij的IDE会在名称和等号之间插入类型（如果可能的话，即使没有任何个性化设置）。
图片如下：

这并不意味着我的观点是对前缀的百分之一百。 当涉及结果时，我非常喜欢将来的后缀版本，因为这感觉更自然。 在没有任何上下文的情况下，我可以轻松分辨出其中的含义是：
future await?
future? await
相反，从新手的角度来看这两个是正确的：
await future? === await (future?)
await future? === (await future)?

我赞成使用前缀关键字： await future 。

它是大多数具有异步/等待功能的编程语言所使用的语言，因此，熟悉其中一种语言的人会立即熟悉它。

至于await future?的优先顺序，常见情况是什么？

• 返回Result<Future>的函数，必须等待。
• 必须等待的Result返回Future<Result> 。

我认为在处理典型方案时第二种情况更为常见，因为I / O操作可能会失败。 因此：

await future? <=> (await future)?

在不太常见的第一种情况下，可以加上括号： await (future?) 。 如果尚未弃用try!宏，这甚至可能是一个很好的用法： await try!(future) 。 这样， await和问号运算符就不会在将来出现分歧。

为什么不将await作为第一个async函数参数？

async fn await_chain() -> Result<usize, Error> {
    let _ = partial_computation(await)
        .unwrap_or_else(or_recover)
        .run(await)?;
}

client.get("https://my_api")
    .send(await)?
    .json(await)?

let output = future
    .run(await);

这里future.run(await)是await future替代。
它可能只是常规的async函数，该函数会占用将来，并仅在其上运行await!()宏。

C ++（并发TR）

auto result = co_await task;

这是在协程TS中，而不是并发。

另一种选择是使用become关键字代替await ：

async fn become_chain() -> Result<usize, Error> {
    let _ = partial_computation_future(become)
        .unwrap_or_else(or_recover_future)
        .start(become)?;
}

client.get("https://my_api")
    .send_future(become)?
    .json_future(become)?

let output = future.start(become);

become可能是保证TCO的关键字

感谢@EyeOfPython的[概述]。 这对于刚加入自行车棚的人们来说尤其有用。

就个人而言，我希望我们远离f await ，因为它在语法上非常简单，并使其显得有些特殊和神奇。 这将成为Rust的新用户感到困惑的许多事情之一，我觉得这值得增加，即使对于Rust的退伍军人也没有增加太多的清晰度。

@novacrazy这个参数的问题是任何await!宏_would_都是魔术，它执行的操作在用户编写的代码中是不可能的

@ Nemo157我同意await!宏是神奇的，但是我认为这不是问题。 std已经有多个这样的宏，例如compile_error!而且我还没有看到有人抱怨它们。 我认为使用宏仅了解其作用而不是其作用是正常的。

我同意以前的评论者的观点，后缀将是最符合人体工程学的，但是我宁愿从前缀宏await!(expr) ，一旦有可能就过渡到后缀宏而不是expr.await （魔术编译器内置字段）或expr.await() （魔术编译器内置方法）。 两者都将为此功能引入一种全新的语法，而IMO只会使该语言感到不一致。

@EyeOfPython介意将future(await)到您的列表和表吗？ 您对future.await()评估的所有积极因素似乎都在转移而没有弱点

由于有人认为尽管语法高亮显示，但foo.await看起来太像字段访问，因此我们可以将令牌.更改# ，而改写foo#await 。 例如：

let foo = alpha()#await?
    .beta#await
    .some_other_stuff()#await?
    .even_more_stuff()#await
    .stuff_and_stuff();

为了说明GitHub如何通过语法突出显示来呈现它，让我们用match替换await ，因为它们的长度相等：

let foo = alpha()#match?
    .beta#match
    .some_other_stuff()#match?
    .even_more_stuff()#match
    .stuff_and_stuff();

这看起来既清晰又符合人体工程学。

#而不是其他令牌的基本原理没有具体说明，但是令牌很明显，这很有帮助。

因此，另一个概念是：如果将来是参考：

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   *self.logger.log("beginning service call");
   let output = *service.exec(); // Actually wait for its result
   *self.logger.log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = *acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = (*logger.log_into(message))?;
    *logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    *(*partial_computation()).unwrap_or_else(or_recover);
}

(*(*client.get("https://my_api").send())?.json())?

let output = *future;

这确实是丑陋且不一致的。 让至少消除歧义的语法：

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   $self.logger.log("beginning service call");
   let output = $service.exec(); // Actually wait for its result
   $self.logger.log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = $acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = ($logger.log_into(message))?;
    $logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    $($partial_computation()).unwrap_or_else(or_recover);
}

($($client.get("https://my_api").send())?.json())?

let output = $future;

更好，但仍然很丑陋（但更糟的是，它使github的语法突出显示）。 但是，为了处理该问题，我们引入了延迟前缀运算符的功能：

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.$log("beginning service call");
   let output = service.$exec(); // Actually wait for its result
   self.logger.$log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = $acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.$log_into(message)?;
    logger.$timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    ($partial_computation()).$unwrap_or_else(or_recover);
}

client.get("https://my_api").$send()?.$json()?

let output = $future;

这正是我想要的！ 不仅用于等待（ $ ），而且还用于deref（ * ）和求反（ ! ）。

使用此语法的一些注意事项：

1. 运算符优先级：对我来说显而易见，但对于其他用户呢？
2. 宏互操作： $符号会在这里引起问题吗？
3. 表达式不一致：前导前缀运算符适用于整个表达式，而延迟前缀运算符仅适用于.分隔符的表达式（ await_chain fn证明了这一点），这令人困惑吗？
4. 解析和实现：该语法是否完全有效？

@Centril
IMO＃太接近原始文字语法r#"A String with "quotes""#

IMO＃太接近原始文字语法r#"A String with "quotes""#

从上下文看来，在这种情况下的区别是很明显的。

@Centril
确实如此，但是语法对于Rust使用IMHO的样式确实很陌生。 它与具有类似功能的任何现有语法都不相似。

@Laaas引入时也没有执行? 。 我很乐意选择.await ; 但是其他人对此感到不满意，因此我试图找到其他可行的方法（例如，清晰，符合人体工程学，易于键入，可链接，具有良好的优先级）， foo#await似乎可以满足所有要求。

?还有很多其他优点，而#await似乎很武断。 无论如何，如果您想要.await ，为什么不选择.await! ？

@Centril这是future(await)背后的主要原理，以避免在不必添加任何额外的运算符或外部语法的情况下进行字段访问。

而#await似乎很武断。

#是任意的，是的-是成败吗？ 当某个时候发明了新语法时，它必须是任意的，因为有人认为它看起来不错或很有意义。

为什么不.await! ？

这同样是任意的，但我对此并不反对。

@Centril这是future(await)背后的主要原理，以避免在不必添加任何额外的运算符或外部语法的情况下进行字段访问。

相反，它看起来像函数应用程序，您在其中将await传递给future ； 这比“现场访问”更令人困惑。

相反，它看起来像函数应用程序，您正在传递给未来。 这比“现场访问”更令人困惑。

对我来说，这就是简洁的一部分。 Await在许多方面都类似于函数调用（被调用者在您和您的结果之间执行），并且向该函数传递关键字可以清楚地表明这是另一种调用。 但是我看到关键字与任何其他参数相似都可能引起混淆。 （减负语法突出显示和编译器错误消息试图增强该消息。除了等待状态外，不能以其他任何方式调用期货，反之亦然）。

@Centril

是任意的是不是一个消极的东西，但有相似之处现有的语法是一件积极的事情。 .await!并不是任意的，因为它不是全新的语法。 毕竟，它只是一个名为await的修复后宏。

为了澄清/补充有关专门用于await新语法，我的意思是引入与现有语法不同的新语法。 有很多前缀关键字，其中一些是在Rust 1.0之后添加的（例如union ），但AFAIK不是单个后缀关键字（无论是否用空格，点或其他分隔） 。 我也想不出具有postfix关键字的任何其他语言。

恕我直言，唯一不会显着增加Rust的陌生性的postfix语法是postfix宏，因为它镜像了方法调用，但以前看过Rust宏的任何人都可以清楚地将其识别为宏。

我也喜欢标准的await!()宏。 简单明了。
我更喜欢像awaited这样的字段访问（或任何其他后缀）共存。

• Await感觉您将等待下一个/正确的事情。 等待着，到达之前/离开的地方。
• 与迭代器上的cloned()方法一致。

我也喜欢@?像?的糖。
这是个人的，但是我实际上更喜欢&?组合，因为@往往太高了并且底线不足，这很分散注意力。 &也很高（很好），但不会下冲（也很好）。 不幸的是， &已经具有含义，尽管它后面总是跟着? ..我想吗？

例如。

Lorem@?
  .ipsum@?
  .dolor()@?
  .sit()@?
  .amet@?
Lorem@?.ipsum@?.dolor()@?.sit()@?.amet@?

Lorem&?
  .ipsum&?
  .dolor()&?
  .sit()&?
  .amet&?
Lorem&?.ipsum&?.dolor()&?.sit()&?.amet&?

对我来说， @感觉像个character肿的角色，分散了阅读量。 另一方面， &?感觉很愉快，不会分散我的阅读兴趣，并且在&和?之间有一个不错的顶部空间。

我个人认为应该使用一个简单的await!宏。 如果后置宏进入该语言，则可以简单地扩展该宏，不是吗？

@Laaas正如我希望的那样，Rust中还没有postfix宏，因此它们是新语法。 另请注意， foo.await!.bar和foo.await!().bar不是相同的表面语法。 在后一种情况下，将有一个实际的后缀和内置宏（需要放弃await作为关键字）。

@jplatte

有很多前缀关键字，其中一些是在Rust 1.0之后添加的（例如union ），

union不是一元表达式运算符，因此在此比较中无关紧要。 Rust中恰好有3个稳定的一元前缀运算符（ return ， break和continue ），所有这些都以!键入。

嗯...有了@我以前的建议看起来会好一点：

client.get("https://my_api").@send()?.@json()?

let output = @future;

let foo = (@alpha())?
    .<strong i="8">@beta</strong>
    .@some_other_stuff()?
    .@even_more_stuff()
    .stuff_and_stuff();

@Centril这是我的意思，因为我们还没有修复后的宏，所以它应该只是await!() 。 我的意思是.await!() FYI。 我认为await不需要作为关键字，但是如果发现问题可以保留它。

union不是一元表达式运算符，因此在此比较中不相关。 Rust中恰好有3个稳定的一元前缀运算符（ return ， break和continue ），所有这些都以!键入。

这仍然意味着即使关键字键入不同，前缀关键字变体也适合一元表达式运算符组。 postfix-keyword变体与现有语法的差异要大得多，在我看来，相对于await在该语言中的重要性而言，差异太大。

关于前缀宏和过渡到后缀的可能性： await需要保持关键字才能起作用。 然后，该宏将是一些特殊的lang项目，其中允许使用关键字作为名称而无需额外的r# ，而r#await!()可以但可能不应调用同一宏。 除此之外，它似乎是最实用的解决方案。

也就是说，将await保留为关键字，但使await!解析为lang-item宏。

@HeroicKatora为什么需要保留一个关键字才能起作用？

@Laaas因为如果要保持转换的可能性，我们需要保持开放状态，以备将来使用它作为关键字的

@Centril

还要注意，foo.await！.bar和foo.await！（）。bar是不同的表面语法。 在后一种情况下，将有一个实际的后缀和内置宏（这需要放弃await作为关键字）。

将关键字await与!为一个内部宏（无法通过常规方法定义），是否可以解决？ 然后，它仍然是关键字，但以其他宏语法解析为宏。

@HeroicKatora为什么x.await!()中的await是保留关键字？

并非如此，但是如果我们不解决补丁后问题，那么它不一定是我们在以后的讨论中得到的解决方案。 如果那是唯一商定的最佳可能性，那么我们首先应该采用这种确切的后缀语法。

这是我们又一次遇到了作为后缀运算符工作得更好的东西。 最大的例子是try! ，我们最终给了它自己的符号? 。 但是，我认为这不是最后一次使后缀运算符更优化，并且我们不能完全赋予其自己的特殊字符。 因此，我认为我们至少不应以@ 。 如果我们有办法做这种事情，那就更好了。 这就是为什么我支持postfix宏样式.await!() 。

let x = foo().try!();
let y = bar().await!();

但是要使后缀宏有意义，就必须引入它们自身。 因此，我认为最好从正常的await!(foo)宏语法开始。 如果我们真的觉得这很重要，可以保证使用自己的符号，则可以稍后将其扩展为foo.await!()甚至foo@ 。
这个宏需要一点魔术对std来说并不陌生，对我来说也不是什么大问题。
正如@jplatte所说：

@ Nemo157我同意await!宏是神奇的，但是我认为这不是问题。 std已经有多个这样的宏，例如compile_error!而且我还没有看到有人抱怨它们。 我认为使用宏仅了解其作用而不是其作用是正常的。

我在这里讨论的一个经常出现的问题是关于链接以及如何使用
等待链接表达式。 也许还有其他解决方案？

如果我们不想将await用于链接而仅将await用于
分配，我们可能会像只是将let替换为await：
await foo = future

然后对于链接，我们可以想象某种操作，例如await res = fut1 -> fut2或await res = fut1 >>= fut2 。

唯一缺少的情况是等待并返回结果，一些快捷方式
为await res = fut; res 。
使用简单的await fut可以轻松完成此操作

我认为我没有见过这样的其他建议（至少对于
链接），因此将其放到我认为很好用的位置。

@HeroicKatora我已将fut(await)到列表中，并根据我的意见对其进行了排名。

如果有人觉得我的得分不对，请告诉我！

在语法方面，我认为.await!()是干净的，并允许链接，而不会在语法中添加任何奇怪之处。

但是，如果我们得到了“真实的”后缀宏，那将有些奇怪，因为大概.r#await!()可能会被遮盖，而.await!()不会。

我强烈反对“ postfix keyword”选项（以foo() await?.bar() await?分隔），因为我发现将await连接到表达式的以下部分这一事实，而不是它所操作的部分。 我会更喜欢除空格以外的任何符号，甚至更喜欢使用前缀语法，尽管它在长链上有缺点。

我认为“明显优先级”（带有await?糖）显然是最好的前缀选项，因为强制分隔符对于等待单个语句的非常常见的情况是一种痛苦，而“有用优先级”根本不是直观，从而造成混乱。

在语法方面，我认为.await!()是干净的，并允许链接，而不会在语法中添加任何奇怪之处。

但是，如果我们得到了“真实的”后缀宏，那将有些奇怪，因为大概.r#await!()可能会被遮盖，而.await!()不会。

如果我们获得后缀宏，并使用.await!()则可以取消保留await作为关键字，而仅使其成为后缀宏。 该宏的实现仍需要一点技巧，但它就像今天的compiler_error!一样，是一个真正的宏。

@EyeOfPython您能否详细说明在forward-compatibility考虑哪些更改？ 我不确定fut@await将以哪种方式评价高于fut.await!()和await { future }低于await!(future) 。 verbosity列也似乎有些奇怪，某些表达式简短但评分较低，是否考虑了链式语句等。其他所有内容似乎都很平衡，并且是迄今为止最简明的广泛评估。

在阅读了此讨论之后，似乎很多人都想添加一个普通的await!()宏并在以后找出后缀版本。 那是假设我们实际上想要一个后缀版本，对于本注释的其余部分，我将采用该版本。

因此，我只想在这里征询大家的意见：现在我们都应该就await!(future)语法达成共识吗？ 优点是该语法没有解析歧义，它也是一个宏，因此无需更改语言的语法即可支持此更改。 缺点是链看起来很丑陋，但这没关系，因为可以很容易地自动用postfix版本替换此语法。

一旦解决了该问题并将其实现到语言中，我们就可以继续讨论后缀等待语法，希望它具有更成熟的经验，想法以及可能的其他编译器功能。

@HeroicKatora我对它的评分较高，因为它可以自然地释放await用作普通标识符，并允许添加其他后缀运算符，而我认为fut.await!()最好是await已保留。 但是，我不确定这是否合理， fut.await!()可能更高也似乎是肯定的。

对于await { future }与await!(future) ，后一个选项保持打开状态，几乎可以更改为其他任何选项，而第一个选项仅允许await future变体中的任何一个（如@withoutboats的博客条目中所述）。 因此，我认为绝对应该是fwd(await { future }) < fwd(await!(future)) 。

至于详细程度，您是正确的，在将案例划分为子组之后，我没有重新评估详细程度，这应该是最客观的一项。

我将对其进行编辑以考虑您的评论，谢谢！

稳定await!(future)是我能想到的最坏的选择：

1. 这意味着我们必须保留await ，这进一步意味着将来的语言设计会变得更加困难。
2. 有意地，它采用与我们弃用的try!(result)相同的路线（并且需要在Rust 2018中编写r#try!(result) ）。
   
   
   
   • 如果我们知道await!(future)是错误的语法，那么我们最终打算弃用它，这将故意增加技术负担。
   
   
   • 而且， try!(..)是在Rust中定义的，而await!(future)不能，而将是编译器魔术。
   
   
   • 弃用try!(..)并不容易，并且会给社会造成巨大的损失。 再次经历这种磨难似乎没有吸引力。
   
   
3. 这将使用宏语法作为语言的核心和重要部分； 这显然不是一流的。
4. await!(future)很吵; 与await future您需要编写!( ... ) 。
5. Rust API，尤其是标准库，以方法调用语法为中心。 例如，在处理Iterator s时链接方法是很平常的事。 与await { future }和await future类似， await!(future)语法将使方法链接变得困难，并导致临时的let绑定。 这对人体工程学和我的可读性都是不利的。

@Centril我想同意，但有一些未解决的问题。 您确定有关1.吗？ 如果我们将其设置为“魔术”，是否可以通过允许其引用宏而不将其作为关键字删除而使它变得更魔术？

我加入Rust太晚了，无法评估2.的社会视角。 重复错误听起来并不吸引人，但是由于某些代码仍未从try!转换而来，因此很明显这是一个解决方案。 这就提出了一个问题，即我们是否打算以async/await作为动机来迁移到版本2018还是耐心等待而不重复此操作。

另外两个（imho）中央功能非常类似于3. ： vec![]和format! / println! 。 前者非常重要，因为没有稳定的盒装构造afaik，后者是由于格式字符串构造并且没有依赖类型的表达式。 我认为这些比较还部分地将4.置于另一个角度。

我反对任何语法读起来都不像英语的语法。 IE，“ await x”读取的内容类似于英语。 “ x＃!! @！＆”不是。 “ x.await”的读法像英语一样诱人，但是当x是不平凡的行时（例如带有长名称的成员函数调用或一堆链接的迭代器方法等），它不会显示。

更具体地说，我支持“关键字x”，其中关键字可能是await 。 我来自同时使用C ++协程TS和unity的c＃协程，它们都使用与之非常相似的语法。 经过多年在生产代码中使用它们的经验，我的信念是，一目了然知道您的屈服点在哪里至关重要。 当您在函数的缩进行上略过时，您可以在几秒钟内挑选出200行函数中的每个co_await / yield return ，而没有任何认知负担。

事后等待的点运算符或某些其他后缀“符号堆”语法不一样。

我相信await是基本的控制流操作。 应该给予它与'if ， while ， match和return相同的尊重水平。 想象一下，如果其中任何一个是后缀运算符-读取Rust代码将是一场噩梦。 就像我等待参数一样，您可以浏览任何Rust函数的缩进线并立即选择所有控制流。 有例外，但它们是例外，不是我们应该争取的东西。

我同意@ejmahler。 我们不应忘记开发的另一面-代码审查。 带有源代码的文件经常被读取然后写入，因此我认为读取和理解然后编写起来应该更容易。 找到屈服​​点对于代码审查非常重要。 我个人将投票给Useful precedence 。
我相信这：

...
let response = await client.get("https://my_api").send()?;
let body: MyResponse = await response.into_json()?;

更容易理解，而不是这样：

...
let body: MyResponse = client.get("https://my_api").send().await?.into_json().await?;

@HeroicKatora

@Centril我想同意，但有一些未解决的问题。 您确定有关1.吗？ 如果我们将其设置为“魔术”，是否可以通过允许其引用宏而不将其作为关键字删除而使它变得更魔术？

从技术上讲？ 可能吧但是，在特殊情况下应该有充分的理由，在这种情况下，魔术般地魔术似乎是不合理的。

这就提出了一个问题，即我们是否打算以async/await作为激励来迁移到版本2018还是耐心等待而不重复此操作。

我不知道我们是否曾经说过要使用新的模块系统， async / await和try { .. }作为奖励； 但不管我们的意图是什么，我认为这是一件好事。 我们希望人们最终开始使用新的语言功能来编写更好，更惯用的库。

另外两个（imho）中央功能非常类似于3. ： vec![]和format! / println! 。 前者非常重要，因为没有稳定的盒装结构afaik，

前者存在，并被写入vec![1, 2, 3, ..] ，以模仿数组文字表达式，例如[1, 2, 3, ..] 。

@ejmahler

“ x.await”的读法像英语一样诱人，但是当x是不平凡的行时（例如带有长名称的成员函数调用或一堆链接的迭代器方法等），它不会显示。

一堆链式迭代器方法有什么问题？ 那显然是惯用的Rust。
rustfmt工具还将在不同行上设置方法链的格式，因此您可以再次使用match来显示语法突出显示：

let foo = alpha().match?  // or `alpha() match?`, `alpha()#match?`, `alpha().match!()?`
    .beta
    .some_other_stuff().match?
    .even_more_stuff().match
    .stuff_and_stuff();

如果您将.await读为“ then await”，那么它至少对我来说很完美。

经过多年在生产代码中使用它们的经验，我的信念是，一目了然知道您的屈服点在哪里至关重要。

我看不到后缀await是如何否定的，尤其是在上面的rustfmt格式中。 此外，您可以编写：

let foo = alpha().match?;
let bar = foo.beta.some_other_stuff().match?;
let baz = bar..even_more_stuff().match;
let quux = baz.stuff_and_stuff();

如果您喜欢的话。

只需几秒钟即可在200行功能中完成，没有任何认知负担。

在不了解特定功能的情况下，在我看来200 LOC可能违反了单一责任原则，并且做得太多。 解决方案是使它做得少一些并拆分。 实际上，我认为这对于可维护性和可读性而言是最重要的。

我相信await是基本的控制流操作。

? 。 实际上， await和?都是有效的控制流操作，它们说“从上下文中提取值”。 换句话说，在本地上下文中，您可以想象这些运算符的类型await : impl Future<Output = T> -> T和? : impl Try<Ok = T> -> T 。

有例外，但它们是例外，不是我们应该争取的东西。

而这里的例外是? ？

@andreytkachenko

我同意@ejmahler。 我们不应忘记开发的另一面-代码审查。 带有源代码的文件经常被读取然后写入，因此我认为读取和理解然后编写起来应该更容易。

围绕最大的可读性和人体工程学的分歧。

更容易理解，而不是这样：

...
let body: MyResponse = client.get("https://my_api").send().await?.into_json().await?;

这不是格式化的方式。 通过rustfmt运行它可以使您：

let body: MyResponse = client
    .get("https://my_api")
    .send()
    .match?
    .into_json()
    .match?;

@ejmahler @andreytkachenko我在这里同意@Centril的观点，前缀语法带来的最大变化（有人可能会说是改进，我不会）是因为用户的动机是将其语句拆分成多行，因为其他所有内容都不可读。 那不是Rust-y，通常的格式设置规则用后缀语法来弥补这一点。 我还认为yieldpoint在前缀语法中比较晦涩，因为await实际上并没有放置在您屈服的代码点，而是相反。

如果您采用这种方式，让我们为清楚起见进行实验，而不是本着await代替let 。 没有其他语法扩展，因为它们看起来像是一个延伸。

await? response = client.get("https://my_api").send();
await? body: MyResponse = response.into_json();

但是对于这些都不是，我没有看到足够的好处来解释它们在语法上的可组合性损失和复杂性。

嗯...既要有前缀又要有后缀形式的await吗？ 还是只是后缀形式？

在谈论时，链接方法的调用特别常见
迭代器和较小程度的选择，但除此之外，锈是
首先是命令式语言，然后是功能性语言。

我不是在说后缀实际上是难以理解的，我叫
认知负载的论点隐藏了顶层控制流操作，
具有与“返回”相同的重要性，当
与将其尽可能靠近行的开头相比-我
基于多年的生产经验来提出这一论点。

2019年1月19日星期六，上午11:59 Mazdak Farrokhzad [email protected]
写道：

@HeroicKatora https://github.com/HeroicKatora

@Centril https://github.com/Centril我想同意，但是有
一些悬而未决的问题。 您确定1.吗？ 如果我们使它“神奇”可以
我们不能通过允许它引用宏而不使其变得更神奇
将其作为关键字删除？

从技术上讲？ 可能吧但是，应该有充分的理由
特殊情况下，在这种情况下似乎无法魔咒
有道理。

这就提出了一个问题，我们是否打算进行异步/等待
迁移到2018版的诱因或宁愿耐心而不是
重复一遍。

我不知道我们是否曾经说过要用于新的模块系统async /
等待，并尝试{..}作为奖励； 但无论我们的意图如何
是的，我认为这是一件好事。 我们希望人们最终
开始使用新的语言功能来编写更好，更惯用的语言
库。

其他两个（imho）中央功能非常类似于3 .： vec！[]和format！/
println!。 前者非常多，因为没有稳定的盒装
建筑afaik，

前者存在，并被写入vec！[1、2、3，..]以模仿数组
文字表达式，例如[1、2、3，..]。

@ejmahler https://github.com/ejmahler

“ x.await”的读法像英语一样诱人，但当x为a时却不会
不平凡的行，例如带有长名称的成员函数调用或一堆
链式迭代器方法等

一堆链式迭代器方法有什么问题？ 那很明显
惯用的Rust。
rustfmt工具还将在不同行上格式化方法链，因此您可以
获取（再次使用match显示语法高亮显示）：

让foo = alpha（）。match？ //或alpha() match? ， alpha()#match? ， alpha().match!()?
.beta
.some_other_stuff（）。match？
.even_more_stuff（）。match
.stuff_and_stuff（）;

如果您将.await读为“ then await”，那么它至少对我来说很完美。

经过多年的生产代码中使用它们，我的信念是，知道一目了然，屈服点在哪里绝对至关重要。

我看不到后缀如何等待，尤其是在rustfmt中
上面的格式。 此外，您可以编写：

let foo = alpha（）。match？; let bar = foo.beta.some_other_stuff（）。match？; let baz = bar..even_more_stuff（）。match; let quux = baz.stuff_and_stuff（）;

如果您喜欢的话。

只需几秒钟即可在200行功能中完成，没有任何认知负担。

在我不太了解特定功能的情况下，在我看来
200 LOC可能违反了单一责任原则，并且确实
太多了。 解决方案是使它做得少一些并拆分。 其实我
认为这对于可维护性和可读性是最重要的。

我相信，等待是基本的控制流程操作。

是吗？ 实际上，等待和？ 都是有效的控制流程操作
说“从上下文中提取价值”。 换句话说，在当地
在上下文中，您可以想象这些运算符的类型为await：impl
未来

-> T和？ ：impl试试->T。

有例外，但它们是例外，不是我们应该做的事情
争取。

例外是？ ？

@andreytkachenko https://github.com/andreytkachenko

我同意@ejmahler https://github.com/ejmahler 。 我们不应该
忘记开发的另一面-代码审查。 包含源代码的文件为
读后写的次数要多得多，因此我觉得应该更容易
阅读并理解后再写作。

围绕最佳可读性和最佳性的分歧
人机工程学。

更容易理解，而不是这样：

...让正文：MyResponse = client.get（“ https：// my_api”）.send（）。await？.into_json（）。await ?;

这不是格式化的方式。 惯用的rustfmt格式
是：

let正文：MyResponse =客户端
.get（“ https：// my_api”）
。发送（）
。比赛？
.into_json（）
。比赛？;

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/rust-lang/rust/issues/57640#issuecomment-455810497 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABGmeocFJpPKaypvQHo9LpAniGOUFrmzks5vE3kXgaJpZM4aBlba
。

@ejmahler我们不同意。 “隐藏”； 提出了同样的理由。

?运算符很短，过去曾被批评“隐藏”返回值。 大多数情况下，代码是读的，而不是写的。 将其重命名为?!将使其两倍长，因此更难忽略。

但是，我们最终使?稳定下来，从那时起，我认为这一预言未能实现。
对我来说，后缀await遵循自然的阅读顺序（至少对于从左到右讲英语的人来说）。 特别地，它遵循数据流顺序。

更不用说语法突出显示：与等待相关的任何内容都可以用明亮的颜色突出显示，因此一眼就能发现它们。 因此，即使我们使用符号代替实际的await单词，在语法突出显示的代码中仍将非常易于阅读和发现。 话虽如此，我仍然更愿意仅使用await一词来进行grepping的原因-如果我们仅使用await一词而不是符号，则更容易将grep代码用于正在等待的任何内容如@或＃，其含义与语法有关。

你们这不是火箭科学吗

let body: MyResponse = client.get("https://my_api").send()...?.into_json()...?;

postfix ...具有极高的可读性，一目了然，而且非常直观，因为您自然地将其读为代码，它在等待未来结果出现时会逐渐消失。 由于每个人以前都已经看到过椭圆形，因此不需要优先级/宏观的恶作剧，也不会因陌生的信号而产生额外的线路噪音。

（对@solson表示歉意）

@ ben0x539这是否意味着我可以访问结果的成员，例如future()....start ？ 还是等待range().....这样的范围结果？ 从目前的省略号..到现在，您对no precedence/macro shenanigans necessary and确切含义是必须是右侧的二元运算符或括号，因此一目了然。

是的 ？ 运算符存在。 我已经承认有
例外。 但这是一个例外。 任何情况下的绝大多数控制流程
Rust程序通过前缀关键字进行。

在2019年1月19日星期六1:51 PM Benjamin Herr [email protected]
写道：

你们这不是火箭科学吗

让正文：MyResponse = client.get（“ https：// my_api”）.send（）...？。into_json（）...？;

postfix ...可读性极强，一目了然，不容错过
直观，因为您自然而然地将其读为代码形式
在等待未来的结果出现时。 没有
优先/宏恶作剧是必需的，并且没有来自
陌生的信号，因为每个人以前都看过椭圆。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/rust-lang/rust/issues/57640#issuecomment-455818177 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABGmen354fhk7snYsANTfp5oOuDb4OLYks5vE5NSgaJpZM4aBlba
。

@HeroicKatora看起来有点虚假，但是可以肯定。 我的意思是，由于它是后缀操作，就像建议的其他后缀解决方案一样，它避免了使用await x?违反直觉的优先级，并且它不是宏。

@ejmahler

是的 ？ 运算符存在。 我已经承认有例外。 但这是一个例外。

有两种适合keyword expr表达式形式，即return expr和break expr 。 前者比后者更普遍。 continue 'label表单实际上并没有计数，因为它是一个表达式，但不是keyword expr表单。 因此，现在您有2个整个前缀关键字一元表达式形式和1个后缀一元表达式形式。 在我们甚至没有考虑?和await比await和return更相似之前，我几乎不称呼return/break expr ?作为例外的规则。

任何Rust程序中的绝大多数控制流都是通过前缀关键字发生的。

如前所述， break expr并不是那么普遍（ break;是更典型的，而return;是更典型的，它们不是一元表达形式）。 剩下的只是早期的return expr; s，对我来说似乎一点也不清楚，这比match ， ? ，只是嵌套if let更普遍else s，以及for循环。 一旦try { .. }稳定下来，我期望?会被更多使用。

@ ben0x539我认为一旦我们准备好使用它们，我们应该为可变参数泛型保留...

我真的很喜欢在这里使用后缀语法进行创新的想法。 它对流程的意义更大，我记得当我们从前缀try!变为后缀?时，代码变得更好

如果我们不喜欢.await的想法，我敢肯定，可以找到一些真正的后缀运算符的创意。 一个示例可能只是使用++或@等待。

:(我只是不想再等了。

每个人都对宏语法感到满意，这个线程中大多数以其他观点开头的人似乎最终都赞成宏语法。

当然这将是一个“魔术宏”，但用户很少关心宏扩展的外观，对于那些这样做的人来说，很容易在文档中解释细微差别。

常规宏语法有点像苹果派，它是每个人的第二喜欢的选择，但因此成为家庭的最喜欢的选择[0]。 重要的是，喜欢尝试！ 我们随时可以更改它。 但最重要的是，我们所有人都越早同意，我们所有人就越早可以开始实际使用它并提高生产力！

[0]（在第一分钟引用） https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=zh-CN

匹配，如果是否允许，则何时，何时让和为所有控制流
使用前缀。 假装中断和继续是唯一的控制流程
关键字令人误解。

2019年1月19日星期六，下午3:37 Yazad Daruvala [email protected]
写道：

:(我只是不想再等了。

每个人都熟悉宏语法，该线程中的大多数人认为
从其他观点开始似乎最终倾向于使用宏语法。

当然它将成为“魔术宏”，但用户很少关心宏
扩展看起来像，对于那些这样做的人，很容易解释
文档中的细微差别。

常规宏语法有点像苹果派，这是每个人的第二个
最喜欢的选项，但结果是家庭最喜欢的选项[0]。
重要的是，喜欢尝试！ 我们随时可以更改它。 但最
重要的是，我们都越早同意就越早开始
实际使用它并提高生产力！

[0]（在第一分钟引用）
https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=zh-CN

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/rust-lang/rust/issues/57640#issuecomment-455824275 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABGmesz5_LfDKdcKn6zMO5uuSJs9lFiYks5vE6wygaJpZM4aBlba
。

@mitsuhiko我同意！ 由于链接的原因，Postfix显得更加粗糙。 我认为我建议的fut@await语法是另一个有趣的选择，似乎没有其他建议那么多的缺点。 我不确定是否离它太远，而更扎实的版本会更好。

@ejmahler

如果使用if，if let，while，while let和for进行匹配，那么所有匹配操作都使用前缀。 假装中断和继续是唯一的控制流关键字，令人沮丧。

完全没有误导。 这些构造的相关语法大致为：

Expr = kind:ExprKind;
ExprKind =
  | If:{ "if" cond:Cond then:Block { "else" else_expr:ElseExpr }? };
  | Match:{ "match" expr:Expr "{" arms:MatchArm* "}" }
  | While:{ { label:LIFETIME ":" }? "while" cond:Cond body:Block }
  | For:{ { label:LIFETIME ":" }? "for" pat:Pat "in" expr:Expr body:Block }
  ;

Cond =
  | Bool:Expr
  | Let:{ "let" pat:Pat "=" expr:Expr }
  ;

ElseExpr =
  | Block:Block
  | If:If
  ;

MatchArm = pats:Pat+ % "|" { "if" guard:Expr }? "=>" body:Expr ","?;

在这里，形式为if/while expr block ， for pat in expr block和match expr { pat0 => expr0, .., patn => exprn } 。 在所有这些形式的后面都有一个关键字。 我想这就是您所说的“使用前缀”的意思。 但是，这些都是块形式，而不是一元前缀运算符。 由于没有一致性或规则可言，因此与await expr的比较具有误导性。 如果要与块形式保持一致，请将其与await block而不是await expr 。

@mitsuhiko我同意！ 由于链接的原因，Postfix显得更加粗糙。

锈是二元的。 它支持命令式和功能性方法。 我认为这很好，因为在不同情况下，每种情况都可能更适合。

我不知道。 两者都感觉很棒：

await foo.bar();
foo.bar().await;

使用Scala已有一段时间，我也很喜欢许多类似的功能。 特别是match和if在Rust中的后缀位置会很不错。

foo.bar().await.match {
   Bar1(x, y) => {x==y},
   Bar2(y) => {y==7},
}.if {
   bazinga();
}

到目前为止的总结

期权矩阵：

• 没有船
• Mehcode
• HeroicKatora
• 亚伦·弗里尔
• Python之眼

选项摘要矩阵（使用@作为标记，但几乎可以是任何东西）：

| 姓名| Future<T> | Future<Result<T, E>> | Result<Future<T>, E> |
| --- | --- | --- ||-
| 前缀| -| -| -|
| 关键字宏| await!(fut) | await!(fut)? | await!(fut?) |
| 关键字功能| await(fut) | await(fut)? | await(fut?) |
| 有用的优先顺序| await fut | await fut? | await (fut?) |
| 明显的先例| await fut | await? fut | await fut? |
| POSTFIX | -| -| -|
| 带关键字的Fn | fut(await) | fut(await)? | fut?(await) |
| 关键字栏| fut.await | fut.await? | fut?.await |
| 关键字方法| fut.await() | fut.await()? | fut?.await() |
| 后缀关键字宏| fut.await!() | fut.await!()? | fut?.await!() |
| 太空关键字| fut await | fut await? | fut? await |
| 关键字| fut@await | fut@await? | fut?@await |
| 印章| fut@ | fut@? | fut?@ |

“ Sigil关键字”的符号_cannot_是# ，因为那样的话，您就无法使用称为r的未来来做到。 ...作为标记，不必像我第一次担心的那样更改令牌化。

更多现实生活中的使用（我在urlo上有多个await其他_real_用例，我将其添加）：

| 姓名| （reqwest） Client |> Client::get |> RequestBuilder::send |> await |> ? |> Response::json |> > ? |
| --- | --- |
| 前缀| -|
| 关键字宏| await!(client.get("url").send())?.json()? |
| 关键字功能| await(client.get("url").send())?.json()? |
| 有用的优先顺序| (await client.get("url").send()?).json()? |
| 明显的先例| (await? client.get("url").send()).json()? |
| POSTFIX | -|
| 带关键字的Fn | client.get("url").send()(await)?.json()? |
| 关键字栏| client.get("url").send().await?.json()? |
| 关键字方法| client.get("url").send().await()?.json()? |
| 后缀关键字宏| client.get("url").send().await!()?.json()? |
| 太空关键字| client.get("url").send() await?.json()? |
| 关键字| client.get("url").send()@await?.json()? |
| 印章| client.get("url").send()@?.json()? |

编辑说明：已向我指出， Response::json还返回Future可能有意义，其中send等待输出IO和json （或结果的其他解释）等待传入的IO。 不过，我将保持原样，因为我认为有意义的是，即使表达式中只有一个IO等待点，链接问题仍然适用。

对于前缀选项似乎有一个大致的共识，即最明显的优先级（以及await?糖）是最可取的。 但是，许多人表示支持后缀解决方案，以使上述链接更加容易。 尽管前缀选择有一个粗略的共识，但似乎对哪种后缀解决方案最好没有共识。 所有建议的选项都容易引起混淆（通过关键字突出显示来缓解）：

• 带关键字的Fn =>使用名为await的参数调用fn
• 关键字字段=>字段访问
• 关键字方法=>方法调用
• 宏（前缀或后缀）=> await是关键字？
• 空格关键字=>可以使单行分组（多行更好吗？）
• Sigil =>在已经被认为重于Sigil的语言中添加新的信号词

其他更激烈的建议：

• 允许同时使用前缀（明显的优先级）和后缀“字段”（将来可以将其应用于更多关键字，例如match ， if等，以使其成为通用模式，但这是不必要的此辩论的附录）[[参考]（https://github.com/rust-lang/rust/issues/57640#issuecomment-455827164）]
• await的模式来解析期货（根本没有链接）[[参考]（https://github.com/rust-lang/rust/issues/57640）]
• 使用前缀运算符，但可以延迟它[[参考]（https://github.com/rust-lang/rust/issues/57640#issuecomment-455782394）]

当然，使用关键字宏await!(fut)进行稳定化基本上可以与上述所有方法兼容，尽管这确实需要使宏使用关键字而不是常规标识符。

如果有人举了一个在大多数情况下都是真实的示例，该示例在一个链中使用两个await ，我很乐意看到它。 到目前为止，没有人共享。 但是，后缀await也很有用，即使您不需要一个链中多次await ，如reqwest示例所示。

如果我错过了此摘要注释上方值得注意的内容，请在urlo上发给我，我将尝试添加它。（尽管我会要求它添加其他人的注释，以避免声音过大。）

就个人而言，从历史上看，我一直优先使用具有明显优先级的prefix关键字。 我仍然认为使用关键字宏await!(fut)将有助于收集有关现实用例中等待发生位置的真实信息，并且仍然允许我们稍后添加非宏前缀或后缀选项。

但是，在编写以上摘要的过程中，我开始喜欢“关键字字段”。 沿多行分割时，“ Space Keyword”感觉很好：

client
    .get("url")
    .send() await?
    .json()?

但在一行上，它使尴尬的休息使表达式的分组效果很差： client.get("url").send() await?.json()? 。 但是，使用关键字字段，在两种形式下看起来都不错： client.get("url").send().await?.json()?

client
    .get("url")
    .send()
    .await?
    .json()?

尽管我认为“关键字方法”会更好，因为它是一种操作。 如果需要，我们甚至可以在Future上使其成为“真实”方法：

trait Future<..> {
    ..
    extern "rust-await" fn r#await(self) -> _;
}

（ extern "rust-await"当然暗示着实际进行等待所需的所有魔法，而实际上并不是真正的fn，它主要是在那里，因为语法看起来像方法，如果是关键字方法。）

允许同时使用前缀（明显的优先级）和后缀“字段” ...

如果选择了任何后缀语法（无论是一起使用，还是代替前缀一），这绝对是以后讨论的一个论据：我们现在拥有既可以使用前缀也可以使用后缀表示法的关键字，正是因为有时优于另一个，所以也许我们可以在合理的情况下都允许它，并在统一规则的同时增加语法的灵活性。 也许这是一个坏主意，也许它会被拒绝，但是如果postix表示法用于await ，那么这绝对是将来的讨论。

我认为不包含等待字符串的语法的可能性很小。

：+1：

在看到一堆示例（例如@mehcode的示例）后，我有一个随机的想法：我记得关于.await的抱怨之一是它太难看了†，但考虑到等待的事情是通常是容易出错的事实，因为它经常是.await? ，无论如何都会吸引更多的注意力。

†如果您使用的内容不会突出显示关键字

@ejmahler

我反对任何语法读起来都不像英语的语法

像request.get().await内容与body.lines().collect() 。 在“一堆链接的迭代器方法”中，我认为_prefix_实际上读起来更糟，因为您必须记住，它们在一开始就说过“ wait”，并且永远不知道什么时候会听到您的声音等待，有点像花园小路的句子。

经过多年在生产代码中使用它们之后，我的信念是，一目了然地知道屈服点在哪里绝对至关重要。 当您在函数的缩进行上浏览时，您可以在几秒钟内挑选出200行函数中的每个co_await / yield返回值，而没有任何认知负担。

这意味着在表达式内部永远不会有任何东西，考虑到Rust具有面向表达式的性质，这是我绝对不会支持的限制。 至少对于C＃的await ，拥有CallSomething(argument, await whatever.Foo()是绝对合理的。

鉴于async _will_出现在表达式的中间，我不明白为什么在前缀中看到比在后缀中看到更容易的原因。

应该给予与“如果，则，匹配和返回”同等的尊重。 想象一下，如果其中任何一个是后缀运算符-读取Rust代码将是一场噩梦。

return （和continue和break ）和while值得注意的是_completely_无用链接，因为它们总是返回!和() 。 尽管出于某种原因您省略了for ，但是我们已经看到使用.for_each()编写的代码很好，并且没有不良影响，尤其是在人造丝中。

我们可能需要使async/await成为主要的语言功能，才能使和平。 它会出现在各种代码中。 它将遍及整个生态系统-在某些地方，它与?一样普遍。 人们将不得不学习它。

因此，我们可能要有意识地关注长时间使用后的语法选择，而不是一开始的感觉。

我们还需要了解，就控制流构造而言， await是另一种动物。 像return ， break ， continue甚至yield这样的构造都可以通过jmp直观地理解。 当我们看到这些时，我们的眼睛会在屏幕上弹起，因为我们关心的控制流正在向其他地方移动。 但是，尽管await影响机器的控制流，但它并不会移动对我们的眼睛和我们对代码的直观理解很重要的控制流。

我们不打算将无条件调用链接到return或break因为这没有任何意义。 出于类似的原因，我们不打算更改优先级规则以适应它们。 这些运算符的优先级较低。 他们将所有内容移到右侧，然后将其返回到某个位置，从而结束该函数或块中的执行。 但是， await运算符希望被链接。 它是表达式不可或缺的一部分，而不是结尾。

在考虑了本主题中的讨论和示例之后，我留下了一种昧的感觉，即我们将后悔令人惊讶的优先规则。

潜行的马候选者现在似乎正在使用await!(expr) ，希望以后能解决更多问题。 在阅读@Centril的评论之前，我可能会支持此功能，以使几乎所有语法都可以使用此重要功能。 但是，他的论点使我相信，这将刚刚结束。 我们知道方法调用链接在Rust中很重要。 这推动了?关键字的采用，该关键字广受欢迎并且非常成功。 使用我们知道会令我们失望的语法确实只是在增加技术负担。

在此线程的早期， @ withoutboats表示只有四个现有选项似乎可行。 其中，只有后缀expr await语法可能使我们长期开心。 此语法不会引起奇怪的优先顺序意外。 它不会强制我们创建?运算符的前缀版本。 它与方法链接很好地协同工作，并且不会破坏从左到右的控制流。 我们成功的?运算符是后缀运算符的先例，与实际中的return ， break相比， await实际上更像? break或yield 。 尽管后缀非符号运算符可能是Rust中的新功能，但是async/await用法已经足够广泛，可以使其迅速熟悉。

尽管后缀语法的所有选项似乎都可行，但是expr await具有一些优点。 此语法清楚表明await是关键字，这有助于强调魔术控制流程。 与expr.await ， expr.await() expr.await! ， expr.await!()等相比，这避免了解释，它看起来像字段/方法/宏，但实际上不在这一种特殊情况下。 我们都会习惯这里的空格分隔符。

将await拼写为@或使用其他不会引起解析问题的符号吸引人。 当然，这是一个足够重要的运营商，对此予以保证。 但是，如果最后必须将其拼写为await ，那就没问题了。 只要它处于后缀位置。

正如某人提到的_real_示例...我维护（根据tokei）23,858行锈代码库，该库非常异步，并使用期货0.1 await （我知道是高度实验性的）。 让我们去（编辑过的）拼写（注意一切都已经通过rustfmt运行了）：

// A
if !await!(db.is_trusted_identity(recipient.clone(), message.key.clone()))? {
    info!("recipient: {}", recipient);
}

// B
match await!(db.load(message.key))? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = await!(client
    .get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send())?
.error_for_status()?;

// D
let mut res =
    await!(client.get(inbox_url).headers(inbox_headers).send())?.error_for_status()?;

let mut res: InboxResponse = await!(res.json())?;

// E
let mut res = await!(client
    .post(url)
    .multipart(form)
    .headers(headers.clone())
    .send())?
.error_for_status()?;

let res: Response = await!(res.json())?;

// F
#[async]
fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let (_, mut res) = await!(self.request(url, Method::GET, None, true))?;
    let user = await!(res.json::<UserResponse>())?
        .user
        .into();

    Ok(user)
}

现在，将其转换为最流行的前缀变体，其中糖的优先级很高。 出于明显的原因，如果没有更好的写法，这还没有经过rustfmt这样的歉意。

// A
if await? db.is_trusted_identity(recipient.clone(), message.key.clone()) {
    info!("recipient: {}", recipient);
}

// B
match await? db.load(message.key) {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = (await? client
    .get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send())
.error_for_status()?;

// D
let mut res =
    (await? client.get(inbox_url).headers(inbox_headers).send()).error_for_status()?;

let mut res: InboxResponse = await? res.json();

// E
let mut res = (await? client
    .post(url)
    .multipart(form)
    .headers(headers.clone())
    .send())
.error_for_status()?;

let res: Response = await? res.json();

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let (_, mut res) = await? self.request(url, Method::GET, None, true);
    let user = (await? res.json::<UserResponse>())
        .user
        .into();

    Ok(user)
}

最后，让我们将其转换为我最喜欢的postfix变体“ postfix字段”。

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()).await? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key).await? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send().await?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send().await?
    .error_for_status()?
    .json().await?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json().await?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true).await?
        .res.json::<UserResponse>().await?
        .user
        .into();

    Ok(user)
}

练习之后，我发现了很多东西。

• 我现在强烈反对await? foo 。 对于简单的表达式来说，它读起来不错，但是对于复杂的表达式， ?感觉很迷茫。 如果必须做前缀，我宁愿有“有用的”优先权。

• 使用后缀表示法使我可以加入语句并减少不必要的let绑定。

• 使用后缀_field_表示法使我强烈希望.await?出现在其等待的事物的行中，而不是用rustfmt的说法出现在其行中。

我感谢上面的省略号后缀符号“ ...”，因为其简洁明了，并且在英语中具有象征意义，表示对其他事物的期待已暂停。 （就像异步行为如何工作一样！），它也可以很好地链接在一起。

let resultValue = doSomethingAndReturnResult()...?;
let resultValue = doSomethingAndReturnResult()...?.doSomethingOnResult()...?;
let value = doSomethingAndReturnValue()....doSomethingOnValue()...;
let arrayOfValues = vec![doSomethingA(),doSomethingB()]...?;
// Showing stacking
let value = doSomethingWithVeryLongFunctionName()...?
                 .doSomethingWithResult()...?;

我怀疑其他选择是否会如此简洁和视觉上有意义。

一种

let mut res: Response = (await client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json())?;

乙

let mut res: Response = await client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json());
let res = res.unwrap();

是否有较长的等待链被认为是一种很好的形式？

为什么不简单地使用常规的Future组合器呢？

实际上，如果您希望在故障时具有备份行为，则某些表达式不能很好地转换为等待链。

我个人认为：

let value = await some_op()
                 .and_then(|v| v.another_op())
                 .and_then(|v2| v2.final_op())
                 .or_else(|| backup_op());

value.unwrap()

读起来比这更自然：

let value = match await some_op() {
    Ok(v) => match await v.another_op() {
        Ok(v2) => await v2.final_op(),
        Err(_) => await backup_op(),
    },
    Err(_) => await backup_op(),
};

value.unwrap()

毕竟，我们仍然拥有零成本期货的全部力量。

考虑一下。

@EyeOfPython我想强调一下，除了future@await @之外，我们还有另一种选择。 我们可以编写future~await ，其中~像半连字符一样工作，并且适用于任何可能的后缀运算符。

连字符-已被用作负运算符和负运算符。 不再好。 但是~用于指示Rust中的堆对象，否则几乎没有任何编程语言使用它。 它为来自其他语言的人们提供了更少的困惑。

@earthengine好主意，但也许只使用future~ ，这意味着等待未来，其中~的工作方式像await关键字。（例如?符号

未来| 结果的未来| 未来的结果
-| -| -
未来〜|未来〜？|未来？

还链接期货，例如：

let res: MyResponse = client.get("https://my_api").send()~?.json()~?;

我看了一下Go如何实现异步编程，并在那里发现了一些有趣的东西。 Go中最接近期货的替代方法是渠道。 而不是await或其他尖叫的语法来等待值，Go通道为此提供了<-运算符。 对我来说，它看起来很干净直接。 以前，我经常看到人们如何赞扬Go的简单语法和良好的异步功能，因此从它的经验中学到东西绝对是一个好主意。

不幸的是，我们不能使用完全相同的语法，因为Rust源代码中的花括号比Go中的大括号更多，这主要是由于泛型。 这使得<-运算符确实很微妙，使用起来并不愉快。 另一个缺点是在函数签名中它可能被视为与->相反，并且没有理由这样考虑。 还有另一个缺点是<-符记本来打算被实现为placement new ，所以人们可能会误解它。

因此，在对语法进行了一些实验之后，我在<-- sigil停了下来：

let output = <-- future;

在async上下文中， <--非常简单，尽管少于<- 。 但是相反，它提供了超过<-和超过前缀await的巨大优势-缩进效果很好。

async fn log_service(&self) -> T {
   let service = self.myService.foo();
   <-- self.logger.log("beginning service call");
   let output = <-- service.exec();
   <-- self.logger.log("foo executed with result {}.", output));
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = <-- acquire_lock();
    let length = <-- logger.log_into(message)?;
    <-- logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    <-- (<-- partial_computation()).unwrap_or_else(or_recover);
}

对我来说，这个运算符比await看起来更独特，更容易发现（它看起来更像代码上下文中的任何其他关键字或变量）。 不幸的是，在Github上，它看起来比我的代码编辑器还薄，但是我认为这不是致命的，我们可以接受。 即使有人感到不舒服，也可以使用不同的语法突出显示或更好的字体（尤其是连字）来解决所有问题。

喜欢这种语法的另一个原因是，从概念上讲，它可以表示为“此处尚不存在”。 从右到左的箭头方向与我们阅读文本的方向相反，这使我们可以将其描述为“来自未来的事物”。 <--运算符的长形也表明“一些持久的操作开始了”。 从future指向的尖括号和两个连字符可能表示“连续轮询”。 而且我们仍然能够像以前一样将其读为“ await”。
不是某种启发，但可能很有趣。

该建议中最重要的是，人体工程学方法链接也是可能的。 我之前提出的延迟前缀运算符的想法在这里很合适。 这样，我们将在前缀和后缀await语法中获得最好的延迟解引用和延迟否定语法。

一直以来，我不确定延迟字在这里是否合适，也许我们应该改用其他名称。

client.get("https://my_api").<--send()?.<--json()?

let not_empty = some_vec.!is_empty();

let deref = value.*as_ref();

运算符的优先级看起来非常明显：从左到右。

我希望这种语法可以减少编写is_not_*函数的需要，该函数的目的只是求反并返回bool属性。 在某些情况下，使用布尔值/取消引用表达式会更加简洁。

最后，我将其应用于@mehcode发布的真实示例，并且我喜欢<--如何在方法调用链中适当强调async函数。 相反，后缀await看起来就像常规的字段访问或函数调用（取决于语法），并且如果没有特殊的语法突出显示或格式设置，几乎不可能将它们区分开。

// A
if db.<--is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.<--load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .<--send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .<--send()?
    .error_for_status()?
    .<--json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .<--send()?
    .error_for_status()?
    .<--json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.<--request(url, Method::GET, None, true)?
        .res.<--json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

毕竟：这就是我要使用的语法。

@novacrazy

是否有较长的等待链被认为是一种很好的形式？ 为什么不简单地使用常规的Future组合器呢？

我不确定是否没有误会您，但这些不是排他性的，您仍然可以使用组合器

let value = some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())
    .or_else(|| backup_op())
    .await;

但这要起作用，不仅需要在FnOnce(T) -> U处，还需要在FnOnce(T) -> impl Future<_>处键入and_then子句。 将来使用链式组合器，其结果只能在没有postfix异常的情况下正常运行：

let result = load_local_file()
    .or_else(|_| request_from_server()) // Async combinator
    .await
    .and_then(|body| serde_json::from_str(&body)); // Sync combinator

在这篇文章中，我将重点讨论后修复情况下的运算符优先级问题。 据我所知，我们有三种可行的选择，至少在某种程度上有效，每种选择都以一个在当前语法中具有这些优先级的后缀表达式为例。 我强烈认为，这些建议都不能改变当前的运营商优先级。

• 方法调用（ future.await() ）
• 字段表达式（ future.await ）
• 函数调用（ future(await) ）

功能上的差异很小但存在。 请注意，我会接受所有这些，这主要是微调。 为了展示它们，我们需要一些类型。 请不要评论示例的人为因素，这是压缩率最高的版本，可同时显示所有差异。

struct Foo<A, F, S> where A: Future<Output=F>, F: FnOnce(usize) -> S {
    member: A,
}

// What we want to do, in macro syntax:
let foo: Foo<_, _, _> = …;
(await!(foo.member))(42)

• 方法调用： foo.member.await()(42)
  绑定最牢固，因此完全没有括号
• 会员： (foo.member.await)(42)
  当这是一个可调用对象时，需要在等待的结果周围加上括号，这与将一个可调用对象作为成员是一致的，否则会与对成员函数的调用混淆。 这也暗示着有人可以用模式来破坏： let … { await: value } = foo.member; value(42)某种程度上？
• 函数调用： (foo.member)(await)(42)
  由于它像函数调用一样需要分解（我们移动成员）的结构。

当我们既不通过成员移动来分解输入结构，也不将结果称为可调用方法时，它们都看起来是相同的，因为这三个优先级类彼此紧随其后。 我们希望期货表现如何？

与方法调用的最佳并行应该只是采用self另一个方法调用。

与成员的最佳并行关系是仅具有隐式成员await ，因此通过从该成员进行迁移而对其进行结构分解，并且此迁移隐式地等待着将来。 这感觉像最难听的。

与函数并行的是调用是闭包的行为。 我希望此解决方案是语言语料库中最干净的一种（因为在语法上与该类型的可能性最相似），但是对于方法调用来说是一些积极的观点，并且.await永远不会比其他方法长。

@HeroicKatora我们可以在libsyntax中使用.await特殊情况，以允许foo.await(42)但这是不一致的/临时的。 但是， (foo.await)(42)似乎是有用的，因为尽管存在期货输出闭包，但它们可能并不那么普遍。 因此，如果我们针对常见情况进行优化，则不必在()上添加.await可能会赢得平衡。

@Centril我同意，一致性很重要。 当我看到几种相似的行为时，我想通过综合推断其他行为。 但是这里.await似乎很尴尬，特别是上面的示例清楚地表明它与隐式解构并行（除非您能在发生这些效果的地方找到不同的语法？）。 当我看到解构时，我立即想知道是否可以将其与let-bindings等一起使用。但是，这将是不可能的，因为我们将解构没有此类成员的原始类型，或者特别是当类型只是impl Future<Output=F> （最不相关的旁注：完成这项工作将带我们回到替代前缀await _ =代替let _ = ，funlyly¹）。

但这并不能阻止我们使用语法本身，我想我可以学习它，如果最终证明它，我将大力使用它，但这似乎是一个明显的弱点。

¹这可能是一致的，同时允许?通过允许?的模式背后的名字

• await value? = failing_future();

匹配Ok一个的一部分Result 。 在其他情况下，这似乎也很有趣，但很不合时宜。 它还将导致同时为await匹配前缀和后缀语法。

但这并不能阻止我们使用语法本身，我想我可以学习它，如果最终证明它，我将大力使用它，但这似乎是一个明显的弱点。

我认为每种解决方案在某些方面或案例上都会有一些缺点。 一致性，人机工程学，可链接性，可读性，……这成为一个问题：程度，案例的重要性，对典型Rust代码和API的适用性等。

如果用户写foo.await(42) ...

struct HasClosure<F: FnOnce(u8)> { closure: F, }
fn _foo() {
    let foo: HasClosure<_> = HasClosure { closure: |x| {} };

    foo.closure(42);
}

...我们已经提供了良好的诊断功能：

5 |     foo.closure(42);
  |         ^^^^^^^ field, not a method
  |
  = help: use `(foo.closure)(...)` if you meant to call the function stored in the
          `closure` field

调整它以适合foo.await(42)似乎是可以实现的。 事实上，据我所看到的，我们知道用户打算(foo.await)(42)时， foo.await(42)是这么写的这可能是cargo fix在编MachineApplicable方式。 确实，如果我们稳定foo.await但不允许foo.await(42)我相信我们甚至可以在以后需要更改优先级，因为起初foo.await(42)不合法的。

可以进行进一步的嵌套（例如，关闭结果的未来-但这并不常见）：
锈
struct HasClosure fn _foo（）->结果<（），（）> {
let foo：HasClosure <_ i =“ 27”> = HasClosure {闭包：Ok（| x | {}）};

foo.closure?(42);

Ok(())

}

例如，结案结果的未来-并非这会很普遍

在任何后缀示例中，多余的后缀?无需修改语法即可使这一点明确。 无需调整。 问题仅在于.member明确地是一个字段，并且需要首先应用移动解构。 我真的不想说这很难写。 我最想说的是，这似乎与其他.member用法不一致，例如可以转换为匹配。 最初的职位在这方面权衡利弊。

编辑：调整以适合future.await(42)可能会导致意外的额外风险，从而使它成为可能a）与闭包不一致，在这种情况下，由于与成员具有相同名称的方法，情况并非如此； b）在我们想对await论证的地方抑制未来的发展。 但是，正如您前面提到的，调整Future返回关闭应该不是最紧迫的问题。

@novacrazy为什么不简单地使用常规的Future组合器？

我不确定您有多少使用Futures 0.3的经验，但是总体期望是不会大量使用组合器，并且主要/惯用用法将是异步/等待。

与组合器相比，异步/等待具有多个优点，例如，它支持跨屈服点的借用。

组合器早在异步/等待之前就存在了，但是异步/等待还是被发明了，这是有充分理由的！

异步/等待在这里保持不变，这意味着它需要符合人体工程学（包括方法链）。

当然，如果愿意，人们可以自由使用组合器，但是为了获得良好的人体工程学，它们不是必需的。

正如@cramertj所说，让我们尝试将讨论重点放在异步/等待，而不是异步/等待的替代方法上。

实际上，如果您希望在故障时具有备份行为，则某些表达式不能很好地转换为等待链。

您的示例可以大大简化：

let value = try {
    let v = await some_op()?;
    let v2 = await v.another_op()?;
    await v2.final_op()?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => await backup_op(),
}.unwrap()

这样可以清楚地知道哪些部分正在处理错误，哪些部分在正常的正常运行中。

这是关于async / await的伟大事情之一：它与语言的其他部分（包括循环，分支， match ， ? ， try等）配合得很好。

实际上，除了await ，如果您不使用Futures，这将是您编写的相同代码。

另一种编写方式，如果您更喜欢使用or_else组合器：

let value = await async {
    try {
        let v = await some_op()?;
        let v2 = await v.another_op()?;
        await v2.final_op()?
    }
}.or_else(|_| backup_op());

value.unwrap()

最重要的是将普通代码移到单独的函数中，从而使错误处理代码更加清晰：

async fn doit() -> Result<Foo, Bar> {
    let v = await some_op()?;
    let v2 = await v.another_op()?;
    await v2.final_op()
}

let value = await doit().or_else(|_| backup_op());

value.unwrap()

（这是对@joshtriplett的评论的回复）。

需要明确的是，你不必加上括号，我提到它，因为有些人说，这太难了没有括号阅读。 因此，括号是一种可选的样式选择（仅适用于复杂的单线）。

在某些情况下，所有语法都受益于括号，但没有一种语法是完美的，这是我们要针对哪种情况进行优化的问题。

另外，重新阅读您的评论后，也许您以为我主张使用前缀await ？ 我不是，我的示例是使用后缀await 。 我总体上喜欢postfix await ，尽管我也喜欢其他一些语法。

我开始对fut.await感到满意，我认为人们的最初反应是“等等，这就是您等待的方式？很奇怪”。 但后来他们为方便而喜欢它。 当然，对于@await也是如此，这远远超过.await 。

使用该语法，我们可以在示例中省去一些租赁：

let value = try {
    some_op().await?
        .another_op().await?
        .final_op().await?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => backup_op().await,
}.unwrap()

let value = try {
    some_op()@await?
        .another_op()@await?
        .final_op()@await?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => backup_op()<strong i="21">@await</strong>,
}.unwrap()

这也使?解包的内容更加清晰，对于await some_op()? ， some_op()是解包还是期待的结果并不明显。

Pa

我并不是想将重点从这里转移开来，而是要指出它不存在于泡沫中。 我们要考虑的事情是如何协同工作。

即使选择了理想的语法，在某些情况下，我仍然想使用自定义的期货和组合器。 那些可以被软弃用的想法使我质疑Rust的整个方向。

与合并器相比，您给出的示例仍然看起来很糟糕，并且生成器开销可能会更慢并且产生更多的机器代码。

就目前而言，所有这些前缀/后缀标记/关键字bikeshedding都是很棒的，但也许我们应该务实，并采用来Rust的用户最熟悉的最简单的选项。 即：前缀关键字

今年将比我们想象的要快。 甚至一月份都完成了。 如果事实证明用户对前缀关键字不满意，则可以在2019/2020版中对其进行更改。 我们甚至可以开一个“事后看来是2020年”的笑话。

@novacrazy

我所看到的普遍共识是，我们希望最早的第三版是2022年。 2018年版很棒，但并非没有代价。 （并且，2018版的要点之一是使异步/等待成为可能，请想象一下，然后说“不，您需要立即升级到2020版！”）

无论如何，即使希望这样做，在版本中也不可能使用前缀关键字->后缀关键字过渡。 有关版本的规则是，需要有一种在X版本中编写惯用代码的方法，这样它可以在没有警告的情况下进行编译，并且在X + 1版本中可以相同地工作。

同样的原因是，如果我们可以就其他解决方案达成共识，我们宁愿不使用关键字宏来保持稳定。 故意稳定一个我们所不希望的解决方案本身就是有问题的。

我认为我们已经表明，即使对于仅具有一个等待点的表达式，后缀解决方案也是最佳的。 但是我怀疑任何提议的后缀解决方案显然都比其他解决方案要好。

只是我的两分钱（我是一个没人，但是我很长时间都在讨论）。 我最喜欢的解决方案是@await后缀版本。 也许您可以考虑使用postfix !await ，例如一些新的postfix宏语法？

例：

let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()!await?
    .error_for_status()?
    .json()!await?;

经过几次语言迭代之后，能够实现我们自己的postfix宏将非常棒。

...所有新的赛格计划

Rust已经是语法/语法沉重的内容，我们保留了await关键字， stuff@await （或其他任何语法）看起来很古怪/难看（我知道是主观的），并且只是临时语法不会与该语言中的其他任何东西集成在一起，这是一个很大的危险信号。

我看一下Go如何实现
... <-...建议

@ I60R ：Go具有非常糟糕的语法，其中充满了即席解决方案，并且是绝对必要的，非常不同于Rust。 该建议再次针对语法/语法非常严格，并且仅针对此特定功能是临时的。

@ I60R ：Go的语法很糟糕

让我们不要在这里抨击其他语言。 “ X具有可怕的语法”不会导致启发和达成共识。

作为Python / JavaScript / Rust用户和计算机科学专业的学生，​​我个人更喜欢前缀await + f.await()两种语言。

1. Python和JavaScript都有前缀await 。 我希望看到await出现在开头。 如果必须深入阅读才能意识到这是异步代码，我会感到非常不安。 凭借Rust的WASM功能，它可能会吸引许多JS开发人员。 考虑到Rust已经有了很多其他新概念，我相信熟悉和舒适非常重要。

2. Postfix await在链接设置中似乎很方便。 但是，我不喜欢.await ， @await ， f await类的解决方案，因为它们看起来像await语法的临时解决方案，而认为.await()作为在future上调用方法。

Rust已经与javascript背道而驰，而await类似于使用函数来表示await来调用函数（即无法通过函数模拟功能），使其与引入async-await的第一定时器混淆。 因此，我认为语法应有所不同。

我已经说服自己，与.await ， .await()可能更可取，尽管本文的其余部分对这一位置进行了对冲。

这样做的原因是await!(fut)必须通过value_消耗fut 。 使它看起来像字段访问是_bad_，因为它没有像前缀关键字那样移动的含义，也没有像宏或方法调用那样移动的含义。

有趣的是，关键字方法语法使它几乎看起来像是隐式的await设计。 不幸的是，Rust无法使用“显式异步，隐式等待”（因此，_please_不要在此线程上重新对其进行诉讼），因为我们希望将async fn() -> T与fn() -> Future<T>相同地使用，而不是激活“隐式等待”行为。

.await()语法看起来像一个隐式等待系统（如Kotlin所用）的事实可能会成为贬低者，并且由于周围的魔力，几乎可以感觉到“隐式异步，隐式等待”的感觉。真正的方法调用.await()语法。 您是否可以在UFCS中将其用作await(fut) ？ UFCS是Future::await(fut)吗？ 除非它在功能上至少可以在语法上与之统一，否则任何看起来像该语言另一维度的语法都会引起问题。

尽管任何后缀解决方案的概念通常比前缀解决方案更可取，但我仍对任何后缀解决方案的优点胜过相同解决方案的缺点表示怀疑。

我有点惊讶，因为该线索充满了似乎是由于可能而提出的建议，而不是因为它们似乎比最初的建议产生了重大的好处。
我们能否停止谈论$ ， # ， @ ， ! ， ~等，而又不提出明显的争论是什么错了与await ，这是一个很好的理解，并已在其他各种编程语言中证明了自己？

我认为https://github.com/rust-lang/rust/issues/57640#issuecomment -455361619上的帖子已经列出了所有不错的选择。

从那些：

• 强制分隔符分隔符似乎很好，至少很明显优先级是这样，而且我们可以阅读其他代码而无需多加说明。 键入两个括号并不是什么坏事。 也许唯一的缺点是它看起来像一个函数调用，即使它是一些不同的控制流操作。
• 有用的优先级可能是更可取的选择。 这似乎是大多数其他语言所走的路，所以它是熟悉且经过验证的。
• 我个人认为，带有空格的postfix关键字在单个语句中看起来很奇怪，并且需要多次等待：
  client.get("url").send() await?.json()? 。 中间的空白看起来不合适。 加上括号对我来说更有意义： (client.get("url").send() await)?.json()?
  但是我发现控制流仍然比前缀变体更难遵循。
• 我不喜欢后缀字段。 await做一个非常复杂的操作-Rust没有可计算的属性，否则字段访问是一个非常简单的操作。 因此，似乎对该操作的复杂性有一个错误的印象。
• 后缀方法可以。 可能会鼓励某些人写很长的陈述，其中有许多等待，这可能会更多地隐藏屈服点。 即使它有所不同，它也再次使事情看起来像方法调用。

由于这些原因，我更喜欢“有用的优先级”后跟“强制性定界符”

Go具有充满特殊解决方案的可怕语法，并且绝对必要，与Rust完全不同。 该建议再次针对语法/语法非常严格，并且仅针对此特定功能是临时的。

@dpc ，如果您完全阅读<--提案，您会看到此语法仅受Go启发，但是在命令式和函数链接上下文中却大不相同且可用。 我也看不到await语法不是临时解决方案，对我来说，它比<--更具体，更笨拙。 类似于使用deref reference / reference.deref / etc代替*reference ，或者使用try result / result.try / etc代替result? 。 除了熟悉JS / Python / etc之外，我或者没有看到使用await关键字的任何优势，无论如何，它应该比具有一致且可组合的语法重要。 我没有看到<--印章有什么缺点，除了它不是await ，这不是普通英语那么简单，用户应该首先了解它的作用。

编辑：这也可能是@ Matthias247帖子的一个很好的答案，因为它提供了一些反对await论点，并提出了一个不受相同问题影响的替代方案

对于我来说，阅读针对<--语法的评论对我来说真的很有趣，而没有引起历史和偏见原因的论据。

让我们提及有关优先级的实际细节：

今天的优先级图表：

运算符/表达式| 关联性
-| -
路径|
方法调用|
字段表达式| 左到右
函数调用，数组索引|
? |
一元- * ! & &mut |
as | 左到右
* / % | 左到右
+ - | 左到右
<< >> | 左到右
& | 左到右
^ | 左到右
\| | 左到右
== != < > <= >= | 需要括号
&& | 左到右
\|\| | 左到右
.. ..= | 需要括号
= += -= *= /= %= &= \|= ^= <<= >>= | 右到左
return break关闭|

有用的优先看跌期权await之前? ，这样它就绑定比更紧密? 。 因此，链中的?将一个“等待”绑定到它之前的所有事物。

let res = await client
    .get("url")
    .send()?
    .json();

是的，具有有用的优先权，即“有效”。 您一目了然知道吗？ 那是坏风格吗（可能）？ 如果是这样，rustfmt可以自动修复该问题吗？

明显的优先级使await _somewhere_低于? 。 我不确定确切的位置，尽管这些细节可能无关紧要。

let res = await? (client
    .get("url")
    .send())
    .json();

您一目了然知道吗？ rustfmt可以将其设置为有用的样式，而不会自动浪费垂直和水平空间吗？

后缀关键字将落在哪里？ 可能是带有方法调用的关键字方法和带有字段表达式的关键字字段，但是我不确定其他对象应该如何绑定。 哪些选项导致await收到令人惊讶的“参数”的最小可能配置？

为了进行比较，我怀疑“强制分隔符”（在摘要中我称之为“关键字函数

@ CAD97要清楚，请记住， .json()也是未来（至少在reqwests ）。

let res = await await client
    .get("url")
    .send()?
    .json()?;

let res = await? await? (client
    .get("url")
    .send())
    .json();

我越喜欢转换复杂的rust表达式（即使那些仅需要1个等待，但是，请注意，在我的20,000+将来的代码库中，几乎每个异步表达式都是一个等待，直接跟着另一个等待），我越不喜欢Rust的前缀。

由于?运算符，因此全部为_。 没有其他语言具有后缀控制流运算符_and_ await ，它们基本上总是与实代码配对。

我的首选仍然是postfix字段。 作为后缀控制运算符，我觉得它需要future.await提供超过future await的紧密视觉分组。 与.await()? ，我更喜欢.await?外观_weird_，所以它会被_noticed_，并且用户不会认为它是一个简单的函数（因此不会问为什么UFCS不起作用） 。

作为支持后缀的另一个数据点，当后缀稳定时，将使rustfix从await!(...)变为我们决定的任何值将非常感激。 我没有看到任何其他信息，但可以毫无疑问地翻译postfix语法，而无需将内容不必要地包装在( ... ) 。

我认为首先我们应该回答以下问题：“我们是否要鼓励在链接上下文中使用await ？”。 我相信普遍的答案是“是”，因此它成为后缀变体的有力论据。 虽然await!(..)是最容易添加的，但我相信我们不应该重复try!(..)故事。 我个人也不同意“链接隐藏了潜在的昂贵操作”这一论点，我们已经有很多链接方法可能非常繁重，因此链接不会带来懒惰。

虽然前缀await关键字对于其他语言的用户来说是最熟悉的，但我认为我们不应该基于该关键字做出决定，而应该专注于长期性，即可用性，便利性和可读性。 @withoutboats讨论了“熟悉预算”，但是我坚信我们不应该仅仅出于熟悉而引入次优解决方案。

现在，我们可能不希望使用两种方法来做同一件事，因此我们不应该同时引入postfix和prefix变体。 假设我们将选项的范围缩小到了后缀变体。

首先让我们从fut await ，我非常不喜欢这个变体，因为它会严重干扰人类解析代码的方式，并且在阅读代码时会引起混乱。 （不要忘记该代码主要用于阅读）

接下来的fut.await ， fut.await()和fut.await!() 。 我认为最一致且最不易混淆的变体将是后缀宏。 我认为仅仅为了保存几个字符而引入一个新的“关键字函数”或“关键字方法”实体是不值得的。

最后基于标记的变体： fut@await和fut@ 。 我不喜欢fut@await变体，如果我们介绍了印记，为什么要麻烦await部分呢？ 我们是否有未来扩展fut@something ？ 如果没有，那简直是多余的。 所以我喜欢fut@变体，它解决了优先级问题，代码变得易于理解，编写和阅读。 可见性问题可以通过突出显示代码来解决。 将此功能解释为“ @等待中”并不难。 当然，最大的缺点是我们将通过非常有限的“预算”来支付此功能，但是考虑到该功能的重要性以及它在异步代码库中使用的频率，我相信从长远来看，它是值得的。 当然，我们可以使用?绘制某些相似之处。 （尽管我们必须为Rust评论家的Perl笑话做好准备）

结论：在我看来，如果我们准备负担“严格的预算”，我们应该选择fut@ ，否则不建议使用fut.await!() 。

在谈论熟悉度时，我认为我们不应该太在乎对JS / Python / C＃的熟悉度，因为Rust处于不同的领域，并且在许多方面已经看起来有所不同。 提供类似于这些语言的语法是短期的，并且奖励目标很低。 当幕后工作原理完全不同时，没有人会选择仅使用熟悉的关键字来选择Rust。

但是要熟悉Go知识，因为Rust处于类似的领域，甚至在哲学上，与Go相比，它与其他语言也更接近。 尽管存在所有偏见，但它们中最有力的优点之一是它们不会盲目复制功能，而是实施确实有理由的解决方案。

IMO，从这个意义上说， <--语法在这里最强

所有这些，让我们记住，Rust表达式可以产生几种链式方法。 大多数语言都不会这样做。

我想提醒一下C＃开发团队的经验：

反对C＃语法的主要考虑因素是运算符优先级await foo？

我确实觉得我可以对此发表评论。 我们对'await'优先考虑了很多，并且在设置所需的表单之前尝试了许多表单。 我们发现的核心内容之一是，对于我们来说，以及想要使用此功能的客户（内部和外部），人们很少真正希望通过异步调用来“链接”任何东西。

人们想要在expr中继续“等待”的趋势很少见。 我们偶尔会看到类似（await expr）.M（）的事物，但是这些事情似乎比做await expr.M（）的人数少一些，而且不太受欢迎。

和

这也是为什么我们不使用任何“隐式”形式表示“等待”的原因。 在实践中，这是人们想清楚考虑的事情，并且他们希望在代码中居于首位，以便他们可以关注它。 有趣的是，甚至几年后，这种趋势仍然存在。 也就是说，有时我们多年后感到遗憾，因为有些东西过于冗长。 某些功能在早期就以这种方式很好，但是一旦人们对此感到满意，便会更适合于使用其他功能。 “等待”情况并非如此。 人们似乎仍然非常喜欢该关键字的重量级性质以及我们选择的优先级。

抵制印记而不是专用（关键字）字词是一个好方法。

https://github.com/rust-lang/rust/issues/50547#issuecomment -388939886

您应该真正听那些拥有数百万用户的家伙。

因此，您不想链接任何东西，只想拥有几个await ，我的经验是相同的。 编写async/await代码已有6年以上了，而我从不想要这样的功能。 Postfix语法看起来确实很陌生，被认为可以解决可能永远不会发生的情况。 Async呼叫确实是一件大胆的事情，因此单行上的几个等待太重了。

人们想要在expr中继续“等待”的趋势很少见。 我们偶尔会看到类似（await expr）.M（）的事物，但是这些事情似乎比做await expr.M（）的人数少一些，而且不太受欢迎。

这似乎是后验分析。 可能导致它们不继续的原因之一是因为在前缀语法中这样做非常尴尬（相当于不想多次在语句中使用try! ，因为它仍然可以通过运算符?读取。

@ I60R ，

1. 我认为熟悉很重要。 Rust是相对较新的语言，人们会从其他语言迁移，如果Rust看起来很熟悉，他们会更容易做出选择Rust的决定。
2. 我对链接方法的兴趣不是很大-调试长链要困难得多，我的事情是链接只是使代码的可读性变得复杂，并且可能仅允许作为其他选项使用（例如.await!()宏）。 前缀形式将迫使开发人员将代码提取到方法中，而不是链接到其中，例如：

let resp = await client.get("http://api")?;
let body: MyResponse = await resp.into_json()?;

变成这样的东西：

let body: MyResponse = await client.get_json("http://api")?;

这似乎是后验分析。 不能继续的原因之一可能是因为用前缀语法这样做非常尴尬。 以上仅考虑优势，不考虑位置。 我想提醒您，C＃不是Rust，并且trait成员可能会改变在结果上调用方法的愿望。

不，这是关于内部C＃团队实验的，因为它同时具有前缀/后缀/隐式形式。 我说的是我的经历，这不仅是我无法看到postfix表单专家的习惯。

@mehcode您的榜样并没有激励我。 reqwest有意识地决定使初始请求/响应周期与响应（主体流）的后续处理分开并发进程，因此应等待两次，如@andreytkachenko所示。

reqwest可以完全公开以下API：

let res = await client
    .get("url")
    .json()
    .send();

要么

let res = await client
    .get("url")
    .send()
    .json();

（后者是and_then之上的简单糖）。

我感到不安的是，这里的许多后缀示例都使用此链作为示例，因为reqwest s和hyper的最佳api决定是将这些东西分开。

老实说，我相信这里大多数等待后缀的示例都应该使用组合器（必要时添加糖）进行重写，或者保留类似的操作并等待多次。

@andreytkachenko

前缀形式将迫使开发人员将代码提取到方法中，而不是像下面这样链接：

那是好事还是坏事？ 对于有N种方法的情况，每种方法都可以导致M次跟踪，开发人员应该提供N * M方法？ 我个人喜欢可组合的解决方案，即使它们更长一些。

变成这样的东西：

let body: MyResponse = await client.get_json("http://api")?;

let body: MyResponse = client.get("http://api").await?.into_json().await?;

@Pzixel

我认为在C＃中，您不会像在Rust中那样拥有太多的链接/功能代码。 还是我错了？ 这使C＃开发人员/用户的体验很有趣，但不一定适用于Rust。 我希望我们可以与Ocaml或Haskell形成对比。

我认为，导致分歧的根本原因是我们中的一些人享受命令式的风格，而一些人则享受实用的风格。 就是这样。 Rust支持两者，并且辩论的双方都希望async与他们通常编写代码的方式相适应。

@dpc

我认为在C＃中，您不会像在Rust中那样拥有太多的链接/功能代码。 还是我错了？ 这使C＃开发人员/用户的体验很有趣，但不一定适用于Rust。 我希望我们可以与Ocaml或Haskell形成对比。

LINQ和函数样式在C＃中非常流行。

@dpc ，
如果您是关于可读性的，那么我会说很多明确的代码，这会更好。根据我的经验，如果方法/函数的名称很好地自我描述，则无需进行后续操作。

如果您有开销的话-Rust编译器非常聪明地内联它们（无论如何我们总是有#[inline] ）。

@dpc

let body: MyResponse = client.get("http://api").await?.into_json().await?;

我的感觉是，这基本上重复了期货API的问题：它使链接更容易，但是该链的类型变得更难以渗透和调试。

难道不是同一论点适用吗？ 算了吗？ 它允许更多的链接，从而使调试更加困难。 但是我们为什么选择呢？ 过度尝试！ 然后？ 为什么Rust偏爱带有构建器模式的API？ 因此，Rust已经做出了很多选择来支持API中的链接。 是的，这可能会使调试更加困难，但是这不是应该在皮棉级别上发生的吗？也许是对于链太大的clippy的新皮棉？ 我仍然需要看到足够的动力，以了解这里的等待方式有何不同。

那是好事还是坏事？ 对于有N种方法的情况，每种方法都可以导致M次跟踪，开发人员应该提供N * M方法？ 我个人喜欢可组合的解决方案，即使它们更长一些。

N和M不一定很大，并且也不是全部都感兴趣/有用。

@andreytkachenko ，

1. 我不同意，这里的熟悉程度被高估了。 从其他语言迁移时，人们首先会寻求进行async-await风格编程的能力，但语法却不完全相同。 如果以不同的方式实现，但可以提供更好的编程体验，那么它将成为另一个优势。

2. 无法调试长链是调试器的局限性，而不是代码风格。 关于可读性，我认为这取决于可读性，强制命令样式在此不必要地受到限制。 如果async函数调用仍然是函数调用，那么不支持链接是令人惊讶的。 而且无论如何， <--是一个前缀运算符，可以在功能链中将其用作附加选项，如您所说

@skade同意。

所有等待较长时间的示例都是代码气味。 可以使用组合器或更新的API更好地解决它们，而不用在后台创建这些生成器意大利面条状态机。 极端速记语法比目前的期货更难以调试。

我仍然的风扇既前缀关键词await和宏await!(...) / .await!() ，与组合async和#[async]发电机功能，正如我在此处的评论中所述。

如果一切正常，则可能会为await!创建一个宏来处理前缀和后缀，并且await关键字仅是async函数内部的关键字。

@skade ，
对我来说，在future上使用组合器的一个很大的缺点是它们将隐藏async函数调用，并且不可能将它们与常规函数区分开。 我想查看所有可悬挂点，因为很有可能将它们用于构建器样式链中。

@ I60R调试长调用链完全不是调试器问题，因为编写这些链的问题是正确的类型推断。 鉴于许多方法都采用通用参数并分发可能绑定到闭包的通用参数，这是一个严重的问题。

我不确定是否使所有悬挂点都可见是该功能的目标。 这由实施者决定。 并且所有建议的await语法版本都是完全可能的。

@novacrazy好点，现在您提到它，作为一名前javascripter，我从不使用等待链，我一直使用then块

我想看起来像

let result = (await doSomethingAsync()
          .then(|result| {
                     match result {
                          Ok(v) => doSomethingAsyncWithFirstResponse(v)
                          Err(e) => Future.Resolve(Err(e))
                      }
            }).then(|result| {
                  Ok(result.unwrap())
            })).unwrap();

我什至不知道它是否可能，我需要查看Rust中的期货

@richardanaya这是完全可能的（不同的语法）。

像Box impl：

impl<T> Box<T> {
    #[inline]
    pub fn new(x: T) -> Box<T> {
        box x
    }
    ...
}

我们可以输入新关键字await和特征Await ，如下所示：

impl<T> Await for T {
    #[inline]
    pub fn await(self) -> T {
        await self
    }
    ...
}

并将await用作方法和关键字：

let result = await foo();
first().await()?.second().await()?;

@richardanaya同意。 多年前，我是首批采用async / await进行Webdev开发的人之一，真正的力量来自将async / await与现有的Promises / Futures

let result = await doSomethingAsync()
                  .and_then(doSomethingAsyncWithFirstResponse);

let value = result.unwrap();

如果您嵌套了期货或期货的结果或期货的结果，则.flatten()组合器可以进一步大大简化该操作。 手动打开和等待每个包装都是不好的形式。

@XX这是多余且无效的。 await仅存在于async函数中，并且仅能在实现Future / IntoFuture的类型上工作，因此不需要新的特征。

@novacrazy ， @richardanaya

可以使用组合器或更新的API更好地解决它们，而不用在后台创建这些生成器意大利面条状态机。 极端速记语法比目前的期货更难以调试。

@novacrazy好点，现在您提到它，作为一名前javascripter，我从不使用等待链，我一直使用then块

组合器在Rusts异步/等待中具有完全不同的属性和功能，例如，关于跨屈服点的借用。 您不能安全地编写与异步块具有相同功能的组合器。 让我们将组合器讨论放在这个线程之外，因为它没有帮助。

@ I60R

对我来说，将来使用组合器的一个很大的缺点是它们会隐藏异步函数调用，并且不可能将它们与常规函数区分开。 我想查看所有可悬挂点，因为很有可能将它们用于构建器样式链中。

您无法隐藏挂起点。 组合者唯一允许做的就是创建其他期货。 在某个时间点，这些必须等待。

请记住，C＃不会出现大多数使用前缀await会将其与（已存在的）后缀?运算符组合的问题。 特别是，关于优先级的问题以及具有两个类似“装饰符”的一般尴尬出现在表达式的相对侧。

@ Matthias247当然，如果确实需要借用数据，请随时使用多个await语句。 但是，通常您只需要移动数据，并且组合器对此非常有效，并且有可能编译为更有效的代码。 有时会被完全优化掉。

同样，真正的力量在于将事物结合在一起。 没有一种正确的方法可以使事情变得如此复杂。 这就是部分原因，我认为所有这些语法都是正确的，如果它不能帮助其他语言的新用户并帮助创建可维护，高性能和可读性的代码。 80％的时间我都怀疑，无论语法是什么，我都会碰到async / await只是为了使用普通期货提供最稳定，性能最佳的API。

在这方面，前缀关键字await和/或混合宏await!(...) / .await!()是最易读，熟悉和易于调试的选项。

@andreytkachenko

实际上，既然我对“熟悉”有所了解，我已经看到了您的帖子并完全同意，我认为有两种类型的熟悉：

1. 使await语法看起来像使用大量await的类似语言。 Javascript在这里非常大，与我们作为社区的WASM功能非常相关。

2. 第二种类型的熟悉度是使仅使用同步代码的开发人员对代码感到熟悉。 我认为等待的最大方面是使异步代码LOOK同步。 这实际上是javascript真正做错的一件事，就是它被规范化了很久，然后对主要是同步开发人员来说完全陌生。

我在JavaScript异步时代提供的一件事，对我来说，回想起来，对开发人员来说更有用的是将诺言/未来分组在一起的能力。 Promise.all（p1（），p2（）），这样我就可以轻松地使工作并行化。 then（）链接始终只是对Javascript过去的承诺的回响，但现在考虑一下，它几乎是过时的和不必要的。

我可能会提供这种等待的想法。 “尝试使异步代码和同步代码之间的差异尽可能小”

@novacrazy异步函数返回一个impl Future类型，对吗？ 是什么使我们无法将await方法添加到Future特征中？ 像这样：

pub fn await(self) -> Self::Output {
    await self
}
...

@XX据我了解，Rust中的async函数使用生成器转换为状态机。 本文是一个很好的解释。 因此await需要一个async函数才能使用，因此编译器可以正确地将它们都转换。 没有async部分， await无法工作。

Future确实具有wait方法，该方法与您的建议类似，但是会阻止当前线程。

@skade ，

但是代码风格如何影响类型推断？ 我看不到用链接式和命令式风格编写的同一代码的区别。 类型应该完全相同。 如果调试器无法解决问题，那肯定是调试器中的问题，而不是代码中的问题。

@ skade ， @ Matthias247 ，

使用组合器，您将在功能链的开始处恰好标记了一个悬浮点。 所有其他内容将隐式包含在内部。 这与使用隐式mut ，对我个人而言，这是Rust中最大的困惑点之一。 一些API会返回期货，而另一些API会返回期货结果-我不希望那样。 如果可能的话，悬挂点应该是明确的，并且适当组合的语法会鼓励

@ I60R let绑定是类型推断的结点，并有助于错误报告。

@novacrazy

所以await需要一个异步函数来工作

可以用返回类型表示吗？ 例如，返回类型为impl Future + Async ，而不是impl Future 。

@skade我一直认为方法调用语法中的.具有完全相同的目的

@dpc

我认为在C＃中，您不会像在Rust中那样拥有太多的链接/功能代码。 还是我错了？ 这使C＃开发人员/用户的体验很有趣，但不一定适用于Rust。 我希望我们可以与Ocaml或Haskell形成对比。

您得到的与Rust一样多。 查看任何LINQ代码，您将看到它。

典型的异步代码如下所示：

async Task<List<IGroping<int, PageMetadata>>> GetPageMetadata(string url, DbSet<Page> pages)
{
    using(var client = new HttpClient())
    using(var r = await client.GetAsync(new Uri(url)))
    {
        var content = await r.Content.ReadAsStringAsync();
                return await pages
                   .Where(x => x.Content == content)
                   .Select(x => x.Metadata)
                   .GroupBy(x => x.Id)
                   .ToListAsync();
    }
}

或者，更一般

let a = await!(service_a);
let b = await!(some_method_on(a, some, other, params));
let c = await!(combine(somehow, a, b));

您不链接调用，而是将其分配给变量，然后以某种方式使用。 当您处理借阅检查器时尤其如此。

我可以同意，您可以在一种情况下链接期货。 当您要处理在通话期间可能导致的错误时。 例如let a = await!(service_a)? 。 这是后缀替代更好的唯一情况。 我在这里可以看到它的好处，但我认为它不会超过所有缺点。

另一个原因： impl Add for MyFuture { ... }和let a = await a + b;大约是多少？

我想提醒一下在postfix await关键字的上下文中的通用类型归类RFC 。 它将允许以下代码：

let x = (0..10)
    .map(some_computation)
    .collect() : Result<Vec<_>, _>
    .unwrap()
    .map(other_computation) : Vec<usize>
    .into() : Rc<[_]>;

非常类似于postfix await关键字：

let foo = alpha() await?
    .beta await
    .some_other_stuff() await?
    .even_more_stuff() await
    .stuff_and_stuff();

格式错误时，同样具有以下缺点：

foo.iter().map(|x| x.bar()).collect(): Vec<_>.as_ref()

client.get("https://my_api").send() await.unwrap().json() await.unwrap()

我认为，如果我们吞下Type Ascription RFC药丸，则应该吞咽fut await以保持一致性。

顺便说一句，您知道这是有效的语法吗？

fn main() {
    println
    !("Hello, World!");
}

但是我在实际代码中看到了零次出现。

请允许我离开。 我认为应该给@fix宏，就像那样。 这些可以作为expr!macro或expr@macro甚至是expr.macro!() 。 我认为第一种选择是可取的。 我不确定它们是否是一个好主意，但是如果我们想提取一个一般概念而不是一个临时解决方案，同时又要等待一个后缀，我们至少应该考虑将后缀宏作为一种潜在的解决方案。

请记住，即使我们将await用作后缀宏，它仍然是一个神奇的宏（例如compile_error! ）。 但是， @ jplatte和其他人已经确定这不是问题。

如果要走那条路线，我将如何处理它，我将首先确切确定后缀宏的工作方式，然后仅允许await作为魔术后​​缀宏，然后再允许自己定义的后缀宏。

乐兴

至于词法分析，这可能是一个问题。 如果我们看expr!macro ，编译器可能会认为有一个名为expr!的宏，然后有一些无效的字母macro 。 但是，应该可以将expr!macro提前到lex的位置，并且当expr后接! ，某些东西将成为postfix宏，直接跟着identifier 。 我不是语言开发人员，我不确定这是否会使词法过于复杂。 我只是假设后缀宏可以采用expr!macro 。

后缀宏会有用吗？

在我脑海中，我想出了其他一些用于postfix宏的用例。 我不认为所有这些都可以通过自定义宏实现，因此我不确定此列表是否超级有用。

• stream!await_all ：等待流
• option!or_continue ：当option为None时，继续循环
• monad!bind ：用于执行=<<而没有将其绑定到名称

stream!await_all

这使我们不仅可以等待期货，还可以等待流。

event_stream("ws://some.stock.exchange/usd2eur")
    .and_then(|exchange_response| {
        let exchange_rate = exchange_response.json()?;
        stream::once(UpdateTickerAction::new(exchange_rate.value))
    })

等效于（在async -stream-esque块中）：

let exchange_rate = event_stream("ws://some.stock.exchange/usd2eur")
    !await_all
    .json()?;

UpdateTickerAction::new(exchange_rate.value)

option!or_continue

这使我们能够解开一个选项，如果它是None ，则继续循环。

loop {
    let event = match engine.event() {
        Some(event) => event,
        None => continue,
    }
    let button = match event.button() {
        Some(button) => button,
        None => continue,
    }
    handle_button_pressed(button);
}

等同于：

loop {
    handle_button_pressed(
        engine.event()!or_continue
            .button()!or_continue
    );
}

monad!bind

这将使我们能够以一种相当粗糙（即以表达为中心）的方式获得单子。 Rust还没有像monads这样的东西，我也不会因为将它们添加到Rust而被出售。 但是，如果要添加它们，此语法可能会很有用。

我从这里带走了以下

nameDo :: IO ()
nameDo = do putStr "What is your first name? "
            first <- getLine
            putStr "And your last name? "
            last <- getLine
            let full = first ++ " " ++ last
            putStrLn ("Pleased to meet you, " ++ full ++ "!")

等同于：

do {
    putStr("What is your first name? ")!bind;
    let first = getLine()!bind;
    putStr("And your last name? ")!bind;
    let last = getLine()!bind;
    let full = first + " " + &last
    putStrLn("Pleased to meet you, " + &full + "!")!bind;
}

或者，更多内联，使用更少的let s：

do {
    putStr("What is your first name? ")!bind;
    let first = getLine()!bind;
    putStr("And your last name? ")!bind;
    putStrLn(
        "Pleased to meet you, " + &first + " " + &getLine()!bind + "!"
    )!bind;
}

评价

我对此非常分歧。 我脑子里的数学家想为await找到一个通用的解决方案，而后缀宏可能是实现它们的一种方法。 我的大脑务实的部分在想：为什么要费心制作一种宏系统已经没人能理解的语言。

但是，从?和await ，我们有两个超级有用的后缀运算符示例。 如果我们发现将来想要添加的其他内容，可能类似于我提到的内容，该怎么办？ 如果已经将它们概括化了，我们可以自然地将它们添加到Rust中。 如果没有，那么每次都必须提出另一种语法，这可能会使语言膨胀得比后缀宏更大。

你们有什么感想？

@EyeOfPython

我提出了非常相似的想法，并确保Rust中的postfix宏是时间问题。
每当处理ndarray切片时，我都会在考虑它：

let view = array.slice(s![.., ..]);

但更好的是

let view = array.slice![.., ..];
// or like you suggested
let view = array!slice[.., ..];
// or like in PHP
let view = array->slice![.., ..];

并且许多组合器可能消失了，例如带有_with或_else后缀的组合器：

opt!unwrap_or(Error::new("Error!"))?; //equal to .unwrap_or_else(||Error::new("Error!"));

@EyeOfPython @andreytkachenko后缀宏当前不是Rust中的功能，恕我直言，IMHO将需要完整的RFC + FCP +实现阶段。

这不是RFC讨论，而是对需要实施的公认RFC的讨论。

因此，在这里讨论它们或为异步语法提出建议并不可行。 这将进一步严重延迟该功能。

为了遏制这一已经很大的讨论，我认为在这里进行讨论是没有用的，可以将其视为已讨论问题之外的内容。

只是有些想法：尽管此线程专门用于await ，但我认为我们以后会对yield表达式进行同样的讨论，它们也可以链接在一起。 因此，我更希望看到可以通用化的语法，但是看起来却如此。

我在这里不使用宏的原因：

1. 为特定于域的内容提供了宏，并且以任何方式使用它们来更改程序控制流或模仿核心语言功能都是过大的
2. Postfix宏将立即被滥用来实现自定义运算符或其他易导致错误代码的esotheric语言功能
3. 他们不鼓励开发适当的语言功能：
   
   
   
   • stream.await_all是组合器的完美用例
   
   
   • option.or_continue和替换_else组合器是空合并运算符的完美用例
   
   
   • monad.bind是if-let链的完美用例
   
   
   • ndarray slicing是const泛型的完美用例
   
   
4. 他们会质疑已经实施的?运算符

@collinanderson

同样可以被链接

为什么在地球上您认为它们可以被束缚？ 真实代码中出现的次数为零，就像上面的println示例一样。

@Pzixel最终Generator::resume可能会取一个值，因此yield expr将具有非()类型。

@vlaff我看不到清楚看到await的参数必须与Type Ascription一致。 他们是完全不同的东西。

另外，Type Ascription是反复尝试的其他功能之一，不能保证_this_会成功。 虽然我不想反对，但TA是将来的RFC，这是关于已接受的功能和已经提出的语法的讨论。

通读许多评论，以添加更多关于为什么等待的摘要（...）似乎是一条非常理想的路径：

1. 它看起来是现有代码最熟悉的，因为熟悉宏
2. 有使用await的现有工作！（...） https://github.com/alexcrichton/futures-await可以帮助减少代码重写
3. 由于postfix宏不在表中，因此它可能永远不会成为语言的一部分，因此请“等待”！ 在非标准情况下，按照RFC似乎甚至没有可能
4. 它为社区提供了更多时间来考虑广泛稳定使用后的长期发展方向，同时提供了一些并非完全不合常规的内容（例如try！（））
5. 可以用作即将到来的yield！（）的类似模式，直到我们找出可以满足等待和yield的正式路径为止
6. 链接可能没有期望的那样有价值，并且通过在多个行上进行多次等待，甚至可以提高清晰度
7. IDE语法荧光笔无需更改
8. （...）宏在看到其他宏用法之后（可能不会减少认知超载）可能不会被其他语言的人抛弃。
9. 这可能是所有稳定过程中最省力的方法

等待！ 宏在这里已经存在，问题在于链接。

我想得越多，后缀对我来说就越好。 例如：

let a = foo await;
let b = bar await?;
let c = baz? await;
let d = booz? await?;
let e = kik? + kek? await? + kuk? await?;
// a + b is `impl Add for MyFuture {}` which alises to `a.select(b)`

允许嵌套任何级别，并且要求可读。 与?和可能的将来的运算符无缝兼容。 对于新手来说似乎有点陌生，但语法收益可能会超过它。

主要原因是await应该是一个单独的关键字，而不是函数调用。 它太重要了，因此它应该在文本中有自己的突出显示和位置。

@Pzixel ， @HeroicKatora ， @skade

例如，参见Python yield和yield from表达式：外部函数可以提供一个值，当生成器恢复时，该值将成为yield的结果。 这就是@valff的意思，与类型归属无关。 因此， yield也将具有!或() 。

从协程的角度来看， yield和await将其挂起，并且可以（最终）返回一个值。 因为它们只是同一枚硬币的两个面。

并抛出另一种语法可能性_square-brackets-with-keyword_，以部分突出显示此内容（使用yield进行语法突出显示）：

let body: MyResponse = client.get("http://api").send()[yield]?.into_json()[yield]?

“ postfix关键字”对我来说最有意义。 后缀使用除空格以外的其他字符分隔future-expression和await对我来说也很有意义，但不适用。 因为那是方法，而await不是方法。 但是，如果您希望将await作为前缀关键字，我喜欢Trait或方法的@XX建议，该建议仅将await self调用那些想要将一堆东西链接在一起的方法（尽管我们可能无法命名方法await ；虽然我认为只是wait就可以了）。 就个人而言，我可能最终会按行进行等待而不是进行过多的链接，因为我发现长链的可读性较差，因此前缀或后缀将对我有用。

[edit]我忘记了wait已经存在并阻碍了未来，所以请轻描淡写。

@roland我专门指的是它，它讨论类型归因： https :

@rolandsteiner所以你写

let body: MyResponse = client.get("http://api").send() await?.into_json() await?;

当我这样写的时候：

let response = client.get("http://api").send() await?;
let body: MyResponse = response.into_json() await?;

@skade噢，抱歉，您的意思与我想的不同。 ：stuck_out_tongue：

@Pzixel最终Generator::resume可能会取一个值，因此yield expr将具有非()类型。

因此， yield也将具有!或() 。

@valff和@rolandsteiner我发现yield不太可能返回恢复值，如果不使生成器语法和/或特征烦人，则很难适应静态类型的语言。 具有恢复参数的原始原型使用关键字gen arg来引用此参数，类似这样的东西在IMO上更可能有效。 从这个角度来看， yield仍将返回()因此不应对await的讨论产生太大影响。

我认为await应该是前缀运算符，因为async是（而且我希望yield也要作为前缀）。 或者将其作为常规方法，然后在后缀位置使用。

但是，我并没有在这里进行所有的研究：为什么还要考虑一个postfix关键字，而Rust没有其他关键字呢？ 这会使语言变得很奇怪。

另外，链接期货，我明白了为什么它会很有趣。 但是连锁等待吗？ 这到底是什么意思？ 未来会返回新的未来吗？ 我们是否希望Rust将这一成语作为头等公民真的是一个如此普遍的成语？ 如果我们真的很在意，我认为我们应该：

1. 选择方法（即foo.await() ）。 它没有引入奇怪的后缀关键字，我们都知道这意味着什么。 我们也可以这样做。
2. 如果我们真的想要一个关键字/破译者，我们可以稍后解决这个问题。

另外，出于个人观点，我讨厌await在postfix关键字中的位置。

前缀await在其他语言中使用是有原因的-它与自然语言匹配。 您不会说“我将等待您的到来”。 尽管已经编写了JavaScript，但我可能还是有些偏颇。

我还要说的是，我认为await -chaining被高估了。 async/await在将来的组合器上的价值在于，它允许使用标准语言构造（例如if ， match等）来顺序地编写异步代码。 无论如何，您将想分手等待。

不要让async/await构成太多的魔术语法，这只是该语言的一小部分。 提议的方法语法（即foo.await() ）与IMO太正交，与常规方法调用正交，并且太神奇了。 proc-macro机制已经到位，为什么不掩盖它呢？

如何在功能定义中使用await关键字而不是async ？ 例如：

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future
}

只能在async上下文中调用此await fn ：

async {
    let n = foo(bar());
}

然后减到let n = (await foo(bar())); 。
然后，除了await关键字之外，特征Future可以实现await -方法，以便在后缀位置使用await逻辑，例如：

async {
    let n = bar().awaited();
}

另外，有人可以向我解释与发电机的关系吗？ 我很惊讶async / await在生成器（甚至稳定器）之前实现。

@phaazon生成器已作为async / await的内部实现详细信息添加到Rust中。 当前没有稳定它们的计划，并且它们仍然需要非实验性的RFC。 （我个人希望使它们稳定下来，但是似乎它们至少要间隔一到两年，可能要等到async / await稳定并且出现了一些经验）。

@XX我认为，如果在函数定义中使用await ，则您正在破坏async的语义。 让我们坚持标准，不是吗？

@phaazon您能否详细说明这如何破坏async语义？

大多数语言使用async引入将要异步的内容，而await等待它。 因此，对我来说，用await代替async有点奇怪。

@phaazon不，不是，而是另外。 完整示例：

async fn bar() -> i32 {
    5 // will be "converted" to impl Future<Output = i32>
}

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future // will be "converted" to i32 in async context
}

async {
    let a = await bar(); // correct, a == 5
    let b = foo(bar()); // correct, b == 5
}

let c = foo(bar()); // error, can't call desugaring statement `await foo(bar())`

如果有效，则有可能实现在链中使用的等待方法：

async {
    let n = first().awaited()?.second().awaited()?;
    // let n = (await (await first())?.second())?;
}

我认为，后缀是否等待“感觉”太神奇并且对语言不熟悉并不重要。 如果我们采用方法语法.await()或.await!()那么只需解释一下Future拥有.await()或.await!()方法在有意义的情况下，您还可以使用它来等待他们。 花5分钟思考它并不难理解，即使您以前从未见过。

此外，如果我们使用prefix关键字，是什么使我们无法编写带有以下内容的板条箱（不完整的伪代码，因为我现在没有基础结构来处理细节）：

trait AwaitChainable {
    fn await(self) -> impl Future;
}

impl<T: Future> AwaitChainable for T {
    fn await(self) -> impl Future {
        await self
    }
}

这样，如果需要，我们可以等待后缀。 我的意思是，即使这不可能，并且我们必须通过编译器神奇地实现后缀等待，我们仍然可以使用上面的示例来解释它的大部分工作原理。 学习起来并不难。

@ivandardi我也这么想。 但是这个定义

fn await(self) -> impl Future {
    await self
}

并不表示只能在async -context中调用该函数。

@XX是的，就像我说的那样，请忽略损坏的伪代码：PI当前没有基础结构来查找应如何在其中编写正确的语法和特征:(试想一下，我写的东西使它只能在异步中被调用上下文。

@XX ， @ivandardi每个定义， await仅在async上下文中有效。 因此，这是非法的：

fn await(self) -> impl Future {
    await self
}

肯定是

async fn await(self) -> impl Future {
    await self
}

只能在async上下文中这样调用：

await future.await()

哪一种会打败整个目标。

进行此工作的唯一方法是完全更改async ，这是不可行的。

@ivandardi我的版本的演变：

fn await(self) -> T { // How to indicate using in async-context only?
    await self
}

锈
await fn await（self）-> T {//因为已经采用异步
等待自我
}

```rust
await fn await(self) -> T {
    self // remove excess await
}

@CryZe @XX你为什么要嘘我？ 我是正确的。

@XX您想要做的是改变异步的含义并完全等待（例如，创建与await上下文有所不同的async上下文）。 我认为语言开发人员不会提供太多支持

@EyeOfPython此定义无法正常工作：

async fn await(self) -> impl Future {
    await self
}

更可能：

#[call_only_in_async_context_with_derived_await_prefix]
fn await(self) -> impl Future {
    self
}

我之所以投票，是因为您忽略了这是假设的伪语法。 从本质上讲，他们的观点是Rust可以添加一种语言可以理解的特殊特性，例如Drop和Copy，从而增加了对该类型调用.await（）的功能，该类型随后可以像await关键字那样与该类型进行交互。 另外，无论如何，投票仍然被认为与RFC不相关，因为重点是要找到一种客观的解决方案，而不是基于主观感受（例如通过赞成/反对投票可视化）的解决方案。

我不明白这段代码应该做什么。 但是与异步等待当前的工作方式无关。 如果您关心它，请将其排除在该线程之外，并为其编写专用的RFC。

@CryZe该类型可用。 叫做未来。 很久以前就达成共识，异步/等待是一种仅用于转换异步代码的机制。 它不是一般的绑定符号。

@ivandari您的后缀等待未等待，但创建了新的未来。 本质上是身份功能。 您不能隐式等待，因为它不是常规函数。

@ Matthias247他们试图建议的是一种让后缀等待方法调用语法的方法。 这样，Rust不需要像我们对？那样引入任意的新符号，例如＃，@或...。 运算符，看起来仍然很自然：

let result = some_operation().await()?.some_method().await()?;

因此，想法是在某种程度上将Future作为一种特殊的方法来等待特质，使编译器将其视为与普通await关键字相同的方式（在这种情况下，您根本不需要使用）并转换异步从那里将代码导入生成器。 然后，您将具有从左到右的适当逻辑控制流程，而不是使用await some_future()?从左到右，并且不需要引入奇怪的新符号。

（所以tl; dr：它看起来像方法调用，但实际上只是后缀等待中）

考虑到后缀语法，我尚未看到的明确提及是错误和选项组合符的普遍性。 在这些地方，rust与所有等待使用的语言最不同-我们拥有.map_err()? ，而不是自动回溯。

特别是这样的事情：

let result = await reqwest::get(..).send();
let response = result.map_err(|e| add_context(e))?;
let parser = await response.json();
let parsed = parser.map_err(|e| add_context(e))?;

的可读性比（我不在乎考虑使用哪种后缀语法）：

let parsed = reqwest::get(..)
    .send() await
    .map_err(add_context)?
    .json() await
    .map_err(add_context)?;

即使是这种默认格式，其行数也要比多变量方法多。 没有多个等待的表达式似乎用postfix-await减少了垂直空间。

我现在不编写异步代码，所以我从无知开始讲话，很抱歉，如果实际上这不是问题，那就太好了。 我只是不想让正确的错误处理符合人体工程学，而只是希望与其他采用不同方式进行错误处理的语言更加相似。

是的，这就是我的意思。 这将是两全其美，允许人们根据情况选择使用前缀还是后缀。

@XX如果无法用用户代码表示，那么我们将不得不求助于编译器以实现该功能。 但是就理解后缀的工作原理而言，我以前发布的解释仍然有效，即使只是表面的理解。

@CryZe ， @XX ，

乍一看，它看上去平滑，但绝对不符合Rust哲学。 甚至迭代器上的sort方法也不会返回self并中断方法调用链以明确分配。 但是，您希望以完全隐式的方式实现与常规函数调用完全相同的效果。 海事组织没有机会。

是的，这就是我的意思。 这将是两全其美，允许人们根据情况选择使用前缀还是后缀。

为什么要成为目标？ Rust不支持所有其他控制流（例如break ， continue ， if等）。除了“这可能在某些意见中看起来更好。

总的来说，我想提醒大家， await是非常特殊的，不是正常的方法调用：

• 跳过等待时，调试器的行为可能会很奇怪，因为堆栈可能会散开并重新建立。 据我所知，使用C＃和Javascript进行异步调试需要花费很多时间。 那些付钱给从事调试器工作的团队！
• 不能在等待点上建立的本地对象可以存储在实际的OS堆栈中。 不必将那些移动到生成的Future中，这最终将改变所需的堆内存（Future所在的位置）。
• 跨等待点借入是为什么生成的期货要求为!Unpin原因，并且给某些现有的组合器和机制带来了很多不便。 可能有可能从将来不会借用的async方法中生成Unpin期货。 但是，如果await是不可见的，那将永远不会发生。
• 可能还有其他意外的借阅检查器问题，当前的async / await状态未涵盖这些问题。

@Pzixel @lnicola

您为C＃提供的示例是绝对必要的，没有像我们在Rust中经常看到的功能样式长链一样。 LINQ语法只是一种DSL，与我在Google上搜索过的foo().bar().x().wih_boo(x).camboom().space_flight();几乎没有什么不同，就像大多数流行的编程语言一样，C＃代码示例看起来是100％必要的。 这就是为什么我们不能只接受langue X的原因，因为它并不相同。

IMO前缀表示法非常适合命令式编码。 但是Rust支持两种样式。

@skade

我不同意您（和其他人）关于功能样式问题的评论。 简而言之-让我们只同意有些人对另一个人很偏爱。

@ Matthias247不，除了看起来好看之外还有其他原因。 这是因为Rust鼓励链接。 您可能会说：“哦，其他控制流机制没有后缀语法，那么为什么还要特别？”。 好吧，这是一个错误的评估。 我们确实有后缀控制流程。 它们只是我们调用的方法的内部。 Option::unwrap_or就像做一个后缀匹配语句。 Iterator::filter就像做一个后缀if语句。 仅仅因为控制流不是链接语法本身的一部分，并不意味着我们还没有后缀控制流。 从这种角度来看，添加一个后缀等待实际上将与我们拥有的保持一致。 在这种情况下，我们甚至可以拥有类似于Iterator工作方式，而不仅仅是等待原始的后缀，我们还可以拥有一些等待组合器，例如Future::await_or 。 无论哪种方式，等待后缀都不只是外观问题，而是功能和生活质量的问题。 否则，我们仍将使用try!()宏，对吗？

@dpc

您为C＃提供的示例是绝对必要的，没有像我们在Rust中经常看到的功能样式长链一样。 LINQ语法只是一种DSL，与foo（）。bar（）。x（）。wih_boo（x）.camboom（）。space_flight（）;无关。 我已经用Google搜索了一下，就像大多数流行的编程语言一样，C＃代码示例看起来是100％必要的。 这就是为什么我们不能只接受langue X的原因，因为它并不相同。

这是不正确的（您可以检查任何框架，例如polly ），但是我不会对此争论。 我看到两种语言都有许多链接代码。 但是，实际上有一种东西可以使一切变得不同。 它被称为Try特质。 C＃与它没有任何相似之处，因此它不会做任何超出await点的事情。 如果收到异常，它将被自动包装并引发给调用者。

Rust并非如此，您必须手动使用?运算符。

如果您必须拥有超过await点的任何东西，则应创建“组合”运算符await? ，扩展语言规则等，或者您可以仅使postfix等待并且事情变得更加自然（一点外来语法，但谁在乎呢？）。

因此，我目前认为将postfix作为更可行的解决方案。 我唯一的建议应该是使用专用的空格分隔关键字，而不是await()或await!() 。

我想我提出了一个合理的理由来证明正常的.await（）方法是正确的。 如果您考虑一下，它与其他任何阻止方式都没有什么不同。 您调用.await（）方法，（可能是绿色的）线程的执行将被暂存，并且在某个时刻执行运行时，然后在某个时刻恢复线程的执行。 因此，出于所有意图和目的，无论您是否有Mutex或std通道都像这样：

let result = my_channel().recv()?.iter().map(...).collect();

或像这样的未来：

let result = my_future().await()?.iter().map(...).collect();

没什么不同它们都在各自的recv（）/ await（）处阻止执行，并且都以相同的方式链接。 唯一的区别是await（）可能在不是操作系统繁重线程的其他执行器上运行（但很可能是在单线程执行器的情况下）。 因此，不鼓励大量的链接会影响完全相同的方式，并且可能会导致实际的短绒。

但是，我的意思是，从编写此代码的人的角度来看，.recv（）或.await（）并没有太大区别，这两种方法都会阻止执行并在结果可用后返回。 因此，出于所有意图和目的，它几乎可以是一种正常方法，不需要完整的关键字。 我们也没有Mutex和std频道的recv或lock关键字。

但是，rustc显然希望将整个代码转换为生成器。 但是，从语言角度来看，这实际上在语义上是否必要？ 我很确定可以编写一个替代的rustc编译器，该编译器通过阻塞实际的OS线程来实现await（输入async fn需要生成一个线程，然后等待将阻塞该线程）。 尽管这将是一个非常幼稚且缓慢的实现，但它在语义上的行为完全相同。 因此，从语义上讲，实际的rustc等待变为生成器这一事实是没有必要的。 因此，我实际上认为rustc将对.await（）方法的调用转换为生成器可以看作是rustc的优化实现细节。 这样，您就可以证明.await（）是一个完整的方法而不是一个完整的关键字，但是仍然有失误地将整个事情变成了生成器。

@CryZe与.recv()我们可以从程序中的任何其他位置安全地中断await ，然后await旁边的代码将不会执行。 这是一个很大的不同，这就是为什么我们不应该隐式地执行await的最有价值的原因。

@ I60R它的

疯狂的主意：隐式等待。 我已移至另一个线程，因为该线程已经太忙于后缀和前缀讨论。

@CryZe

我想我提出了一个合理的理由来证明正常的.await（）方法是正确的。 如果您考虑一下，它与其他任何阻止方式都没有什么不同。

请再次阅读https://github.com/rust-lang/rust/issues/57640#issuecomment -456147515

@ Matthias247这些都是非常好的观点，好像我错过了那些。

从根本上讲，所有关于将await变成函数，成员或其他隐式的说法都是无效的。 这不是一个行动，而是一个转变。

高层编译器，无论是通过关键字还是宏，都将await表达式转换为特殊的生成器yield表达式，就地解决了借用和其他问题。

这应该是明确的。

它要么尽可能像关键字一样美观，要么显然使用宏生成代码。

魔术方法，特质，成员等都容易被误解和误解，尤其是对于新用户而言。

Prefix关键字await或prefix宏await似乎是执行此操作的最可接受的方法，这与许多其他语言一样是有意义的。 我们不必太特殊才能使其变得更好。

@novacrazy

魔术方法，特质，成员等都容易被误解和误解，尤其是对于新用户而言。

您可以对此进行扩展吗？ 如果可能，更具体地讲.await!()变体。

在我看来，拥有foo.await!()并不难读，尤其是带有适当的语法突出显示，这一点不容忽视。

误会了吗？ 本质上是做什么的（忽略类型mystakes）：

trait Future {
    fn await!(self) -> Self::Item {
        await self
    }
}

又名await this_foo和this_foo.await!()完全相等。 有什么容易误解的呢？

关于新用户的话题：新用户要做什么？ 总体而言是编程，还是将Rust用作语言但具有编程语言背景的新用户？ 因为如果是前者，那么我怀疑他们是否会涉足异步编程。 如果是后者，则更容易解释后缀等待的语义（如上所述），而不会造成混淆。

或者，如果仅添加前缀await，则我所知道的一切都不会停止创建以形式Rust代码作为输入的程序

foo.bar().baz().quux().await!().melo().await!()

并将其转化为

await (await foo.bar().baz().quux()).melo()

@ivandardi

.await!()在某些情况下很好，并且可能与await!(...)例如：

macro_rules! await {
    // prefix
    ($fut:expr) => {...}

    // postfix
    ($self:Self) => { await!($self) }
}

但是，后缀方法宏现在不存在，并且可能永远不存在。

如果我们认为将来有可能，我们现在应该使用宏await!(...) ，并在实现后在将来简单地添加后缀。

拥有两个宏将是理想的选择，但是如果将来不打算实现后缀宏，则前缀关键字await可能是最好的选择。

@novacrazy我可以同意，这是我最初的建议。 我们现在应该添加await!()并在我们进行时找出一个后缀形式。 可能还会讨论postfix宏的可能性，以及如果我们可以在语言中完全支持postfix宏之前将postfix .await!()临时添加到该语言中。 Kinda就像?和Try特性发生的事情一样：它是作为特殊情况首先添加的，之后又被扩展为更一般的情况。 决定时，我们唯一需要注意的是一般的postfix宏语法如何，这可能值得单独讨论。

Prefix关键字await或prefix宏await似乎是执行此操作的最可接受的方法，这与许多其他语言一样是有意义的。

显然是_workable_，但是我只记得两个参数，但我认为它们没有说服力：

• 其他语言就是这样
  
  
  
  • 很好，但是我们已经在做一些不同的事情，例如not-running-unless- poll ed而不是运行到第一个await ，因为锈是根本不同的语言
  
  
• 人们喜欢在行首看到await
  
  
  
  • 但这并不总是存在的，所以如果这是一个唯一的地方，一个人就会遇到问题
  
  
  • 就像在foo(aFuture.await, bFuture.await)看到await一样容易
  
  
  • 在锈病中，如果您要查看控制流程，已经在$ _ ?的行的_end_进行扫描
  
  

我错过了什么？

如果辩论是“嗯，他们几乎都是一样的”，我绝对同意“好吧，如果我们不在乎我们也可以做其他人所做的事情”。 但是我不认为这是我们要去的地方。

@scottmcm是的，“嗯，它们

因此，我们应该在可读性，熟悉性，可维护性和性能之间找到适当的平衡。 因此，我的最后一条评论中的语句为true，如果以后打算添加后缀方法宏（ .await!() ），或者只是一个无聊的前缀关键字await ，则使用宏await!()否则await 。

我说无聊，因为无聊是件好事。 当我们用这些编写代码时，我们想让自己的思维远离语法本身。

如果f.await()不是一个好主意，那么我更喜欢前缀语法。

1. 作为用户，我希望我使用的语言只有少数语法规则，并且使用这些规则，我可以可靠地推断出它可能正在做什么。 在这里和那里都不例外。 在Rust中， async开头， await开头也不例外。 但是， f await可以是post关键字形式。 f.await看起来像字段访问，是一个例外。 f.await!()具有postfix宏，该宏从未在该语言中出现，并且不知道它在其他情况下会带来什么好处（例外） 。 我们没有答案如何将这些语法变成规则而不是一次性例外。

2. 当出现例外时，我希望它具有直观的意义。 以?为例，由于在其他语言中不常见，因此可以将其视为例外。 f()?.map()读取的内容几乎与compute f（）相同，这是一个很好的结果吗？ 这里的?自我解释。 但是对于f await我问为什么是后缀？对于f.await我问是await一个字段， f.await!()我问为什么宏出现在那个位置？ 至少乍一看，它们并没有为我提供令人信服/直觉的感觉。

3. 扩展第一点，Rust最想成为一种系统语言。 这里的主要参与者C / C ++ / Go / Java都势在必行。 我也相信大多数人是从命令性语言开始的，C / Python / Java而不是Haskell等开始了我的职业生涯。我想说服系统开发人员和下一代开发人员采用Rust，Rust必须首先以命令性风格做好事，然后再发挥功能，而不是具有高度的功能性，但没有熟悉的当务之急。

4. 我认为将一条链分割成几行是没有错的。 不会很冗长。 这只是明确的。

当看到讨论如何不断地从一个方向移动到另一个方向（前缀与后缀）时，我强烈认为await关键字存在问题，我们必须完全退出。 相反，我提出以下语法，我认为这将是当前线程中发表的所有观点之间的很好折衷：

// syntax below is exactly the same as with prefix `await`
let response = go client.get("https://my_api").send();
let body: MyResponse = go response.into_json();

第一步，我们将其实现为常规前缀运算符，而不会在处理特定的上层结构时出现任何错误：

// code below don't compiles because `?` takes precedence over `go`
let response = go client.get("https://my_api").send()?;
let body: MyResponse = go response.into_json()?;

第二步，我们将实现延迟的前缀运算符语法，该语法也将允许正确的错误处理。

// now `go` takes precedence over `?` if present
let response = client.get("https://my_api").go send()?;
let body: MyResponse = response.go into_json()?;

就这样。

现在，让我们看一些提供更多上下文的示例：

// A
if db.go is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.go load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .go send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .go send()?
    .error_for_status()?
    .go json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .go send()?
    .error_for_status()?
    .go json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.go request(url, Method::GET, None, true)?
        .res.go json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   go self.logger.log("beginning service call");
   let output = go service.exec();
   go self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = go acquire_lock();
    let length = logger.go log_into(message)?;
    go logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    go (go partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").go send()?.go json()?;

// A
if db.as is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.as load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .as send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .as send()?
    .error_for_status()?
    .as json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .as send()?
    .error_for_status()?
    .as json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.as request(url, Method::GET, None, true)?
        .res.as json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   as self.logger.log("beginning service call");
   let output = as service.exec();
   as self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = as acquire_lock();
    let length = logger.as log_into(message)?;
    as logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    as (as partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").as send()?.as json()?;

IMO在每个方面都比其他语法更好：

✓一致性：在Rust代码内部看起来非常有机，不需要破坏代码样式
✓可组合性：与其他Rust功能（如链接和错误处理）很好地集成
✓简单：简短，描述性强，易于理解且易于使用
✓可重用性：延迟前缀运算符语法在其他情况下也将很有用
✓文档：意味着呼叫方将流分派到某个地方并等待直到返回
✓熟悉：提供了已经熟悉的模式，但折衷较少
✓可读性：读为普通英语，不会扭曲单词的含义
✓可见性：其位置使得很难掩饰在代码中的某处
✓可达性：可以很容易地用谷歌搜索
✓经过良好测试：golang如今以某种相似的语法广受欢迎
✓惊喜：很难误解以及滥用该语法
✓满意：少量学习后，每个用户都会对结果感到满意

编辑：正如@ivandardi在下面的评论中指出的，应该澄清一些事情：

1.是的，这种语法有点难以理解，但同时不可能在此处发明不会带来任何可读性问题的语法。 go语法对我来说似乎不太邪恶，因为在前缀位置它与前缀await完全相同，而在延迟位置中，IMO比后缀await更具可读性例如：

match db.go load(message.key) await {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

其中await看起来并不模棱两可，并且与所有现有关键字都不具有不同的关联性，但是如果我们决定将来某个时候实现await块，则也有可能成为阻碍者。

2.将需要创建RFC，实现和稳定“延迟前缀运算符”语法。 该语法不是特定于异步代码的，但是在异步中使用它是其主要动机。

3.在“延迟前缀运算符”中，语法关键字很重要，因为：

• long关键字会增加变量和方法之间的空间，不利于可读性
• 长关键字是前缀运算符的奇怪选择
• 当我们希望异步代码看起来像同步时，long关键字不必要地冗长

无论如何，很有可能开始使用await代替go ，然后在2022年版中对其进行重命名。 到那时，很有可能会发明不同的关键字或运算符。 我们甚至可以决定根本不需要重命名。 我发现await也是可读的。

// A
if db.await is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.await load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .await send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .await send()?
    .error_for_status()?
    .await json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .await send()?
    .error_for_status()?
    .await json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.await request(url, Method::GET, None, true)?
        .res.await json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   await self.logger.log("beginning service call");
   let output = await service.exec();
   await self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = await acquire_lock();
    let length = logger.await log_into(message)?;
    await logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    await (as partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").await send()?.await json()?;

如果您不赞成投票，请确保：

• 您理解得正确，因为我可能不是解释新事物的最佳人选
• 您的观点没有偏见，是因为语法有很多偏见
• 您将在下面提出一个正当的理由，因为无声小票的毒性很大
• 您的原因不是关于立即的感受，因为我在这里尝试设计了长期功能

@ I60R

我确实对此有所了解。

match db.go load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

这有点难以理解。 乍一看，您会认为我们会在db.go上进行匹配，但是接下来还有其他事情，您会发现“哦，好的，加载是db的方法”。 IMO认为语法主要是行不通的，因为方法应始终靠近它们所属的对象，并且它们之间没有空格和关键字中断。

第二，您的建议要求定义什么是“延迟前缀运算符语法”，并可能首先在语言中对其进行概括。 否则，它将仅用于异步代码，我们回到“为什么不后缀宏？”的讨论。 太。

第三，我认为关键字根本不重要。 但是，我们应该偏向于await因为该关键字已为2018年版保留，而go关键字没有并且应该进行更深入的crates.io搜索，然后再提出。

当看到讨论如何不断地从一个方向转到另一个方向（前缀与后缀）时，我强烈认为await关键字存在问题，我们必须完全退出。

我们可能会（半）隐式等待，一切都会好起来的，但是，尽管事实上异步功能的全部要点是隐藏实现细节并使它们看起来只是一个事实，但在Rust社区这将是一件很难的事。像阻止io一样。

@dpc我的意思是，我能想到的最好方法是在半隐式等待和希望显式等待代码段之间达成妥协，类似于unsafe 。

let mut res: Response = await { client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()?
    .error_for_status()?
    .json()?
};

await块中的所有内容都将自动等待。 这样就解决了需要后缀等待链接的需求，因为您可以等待整个链。 但同时，我不确定是否需要这种形式。 也许其他人可以找到一个很好的理由反对这一点。

@dpc异步功能的重点不是隐藏细节，而是使它们更易于使用和使用。 我们绝不应该隐藏潜在的高成本运营，并应尽可能利用明确的期货。

任何人都无法将异步功能与同步功能混为一谈。 纯粹是以更具可读性和可维护性的形式组织操作序列，而不是手写状态机。

另外，如@ivandardi的示例所示，隐式等待将使无法使用Future组合器，正如我已经显示的那样，它们仍然非常强大。 我们不能只抓住任何Future并等待它，那将是非常低效的。

显式，熟悉，可读，可维护和高性能：前缀关键字await或宏await!() ，将来可能带有后缀宏.await!() 。

@novacrazy即使选择了理想的语法，在某些情况下我仍然想使用自定义的

当然，您可以继续使用组合器，不推荐使用任何东西。

这与?情况相同：新代码通常将使用? （因为它比组合器要好），但是Option / Result组合器仍然可以使用（和or_else类的时髦器

特别是，async / await可以完全替换map和and_then ，但是仍然可以使用（而且将继续使用）时髦的Future组合器。

与合并器相比，您提供的示例看起来仍然很糟糕，

我不这么认为，我认为它们更加清晰，因为它们使用标准的Rust功能。

清晰度很少涉及字符数，但它与心理概念有关。

使用后缀await看起来更好：

some_op().await?
    .another_op().await?
    .final_op().await

您可以将其与原始版本进行比较：

some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())

生成器的开销可能会稍慢一些，并产生更多的机器代码。

为什么您声称异步/等待会产生额外的开销？ 生成器和异步/等待都经过专门设计，以实现零成本和高度优化。

特别是，异步/等待编译为高度优化的状态机，与Future组合器相同。

而不是在后台创建这些发电机意大利面条状态机。

Future组合器还在引擎盖下创建了一个“意大利面条状态机”，这正是他们的设计意图。

从根本上说，它们与异步/等待没有什么不同。

[未来组合器]具有编译为更高效代码的潜力。

请停止散布错误信息。 特别是，异步/等待可能比Future组合器更快。

如果事实证明用户对前缀关键字不满意，则可以在2019/2020版中对其进行更改。

正如其他人所说，版本并不是我们随心所欲地制作的随心所欲的东西，它们是专门为每隔几年（最早）而设计的。

正如@Centril指出的那样，想出一种不好的语法来稍后替换它是一种非常低效的处理方式。

目前讨论的速度很高。 因此，为了减慢速度并允许人们赶上来，我暂时锁定了此问题。 它将在一天内解锁。 届时，请尽量保持建设性。

一天后解锁问题...请考虑不要提出要点，并保留有关主题的评论（例如，这里不是考虑隐式等待或其他超出范围的地方。）

由于这是一个冗长的话题，因此让我们重点介绍其中包含的一些最有趣的评论。

@mehcode为我们提供了广泛的真实世界代码，在前缀和后缀位置均带有await ： https :

@Centril有说服力地指出，稳定await!(expr)等于故意增加技术债务： https :

@valff提醒我们expr await postfix关键字语法最适合一般类型的用法： https :

@quodlibetor强调了Error和Option组合https :

最终，lang团队需要在这里打电话。 为了确定可能导致共识的共识，总结lang团队成员在后缀语法关键问题上的立场可能会有所帮助：

• @Centril表示支持后缀语法，并探索了该票证中的许多变体。 Centril特别不想稳定await!(expr) 。

• @cramertj表示支持后缀语法，特别是对expr await后缀关键字语法的支持。

• @joshtriplett表达了对后缀语法的还应提供一个前缀版本。

• @scottmcm表示支持后缀语法。

• @withoutboats不想稳定宏语法。 在担心耗尽我们的“陌生预算”的同时，withoutboats认为expr await postfix关键字语法具有“真正的优势”。

• @aturon ， @eddyb ， @nikomatsakis和@pnkfelix尚未就问题＃57640或＃50547中的语法表达任何立场。

因此，我们需要找出是/否答案：

• 我们应该有前缀语法吗？
• 我们应该有后缀语法吗？
• 我们现在应该拥有前缀语法，之后再找出后缀语法吗？

如果我们使用前缀语法，那么我认为人们最接受两个主要的竞争者：有用和显而易见，如本注释所示。 反对await!()的论点非常强烈，因此我考虑将其排除在外。 因此，我们需要弄清楚是想要有用的语法还是显而易见的语法。 我认为，一般而言，无论哪种语法都应使用较少的括号。

至于后缀语法，这比较棘手。 带有空格的后缀await关键字也有很强的参数。 但这很大程度上取决于代码的格式。 如果代码格式不正确，则带有空格的后缀await关键字看起来确实很糟糕。 因此，首先，我们需要假设所有Rust代码都将使用rustfmt正确格式化，并且让rustfmt始终将链式等待拆分成不同的行，即使它们适合在一行中也是如此。 如果我们能够做到这一点，那么该语法就可以了，因为它解决了单行链中间的可读性和空格混淆的问题。

最后，如果我们同时使用前缀和后缀，则需要弄清楚并写下这两种语法的语义，以了解它们如何相互影响以及如何将它们转换为另一种。 应该可以这样做，因为在后缀或前缀等待之间进行选择不应更改代码的运行方式。

为了阐明我的思考过程，以及我如何处理和评估表面句法建议。 await ，
这是我的目标（没有任何重要顺序）：

1. await应该仍然是启用将来语言设计的关键字。
2. 语法应该是一流的。
3. 一般而言，等待应该可以与?和方法组合在一起，因为它们在Rust中很普遍。 不应强迫人们制作可能不是有意义的细分的临时let绑定。
4. grep对于等待点应该很容易。
5. 应当一目了然地看到等待点。
6. 语法的优先顺序应该直观。
7. 该语法应与IDE和肌肉内存很好地结合在一起。
8. 语法应该易于学习。
9. 语法应符合人体工程学。

在定义（并可能忘记了...）我的一些目标之后，以下是摘要和我对与这些目标有关的一些建议的评估：

1. 保留await作为关键字使得无论是await!(expr)还是expr.await!()很难使用基于宏的语法。 要使用宏语法，将await作为宏进行硬编码并且不与名称解析集成（即use core::await as foo;变得不可能），或者将await完全放弃为关键字。

2. 我相信宏对它们具有明显的非一流的感觉，因为它们旨在在用户空间中发明语法。 尽管这不是技术要点，但在这种语言的中央结构中使用宏语法会给人留下粗糙的印象。 可以说， .await和.await()语法也不是最一流的语法。 但不如宏的感觉那么二等。

3. 促进链接的愿望使得任何前缀语法都无法正常工作，而后缀语法自然会与方法链（尤其是? ）组成。

4. 使用await关键字（无论它是后缀，前缀，宏等）时，最简单的进行抓包。使用基于符号的语法时，例如# ， @ ， ~ ，grepping变得更加困难。 差别不大，但是.await比await和await稍微更容易grep，因为这两个都可以作为注释中的单词包含进来，而对于.await 。

5. 印记可能很难一目了然，而await更容易看清，尤其是语法突出显示。 已经建议.await或其他后缀语法很难一目了然，或者后缀await提供的可读性很差。 但是，在我看来， @ scottmcm正确地指出，结果的未来很普遍， .await?有助于引起人们更多的注意。 此外，Scott指出，前缀await导致花园路径语句，并且表达式中间的await比后缀可读性更高。 随着?运算符的出现，Rust程序员已经需要扫描行尾以查找控制流。

6. .await和.await()的优先级是可以完全预测的。 它们充当字段访问和方法调用的对等对象。 后缀宏的优先级可能与方法调用的优先级相同。 同时，相对于? （即await (expr?) ），前缀await具有一致，可预测且无用的优先级，或者优先级不一致且有用（即(await expr)? ）。 可以给标记指定所需的优先级（例如，从?获得直觉）。

7. @nikomatsakis在2012年指出，西蒙·佩顿·琼斯（ Simon Peyton Jones “点的力量”以及它如何提供IDE魔术，从而使您可以缩小想要的功能或范围。 由于点的力量存在于许多流行的语言（例如Java，C＃，C ++，..）中，因此导致“伸手去拿点”根深蒂固在肌肉记忆中。 为了说明这种习惯的强大功能，以下是带有Re＃er的Visual Studio @scottmcm的屏幕截图：
   

   C＃没有后缀等待。 但是，它非常有用，以至于它在自动完成列表中显示时都没有有效的语法。 但是，当.await不是表面语法时，尝试使用.aw可能不会发生，包括我自己在内。 如果可以的话，请考虑对IDE体验的好处。 await expr和expr await语法没有提供这种好处。

8. 印记可能会提供较差的熟悉度。 前缀await受益于C＃，JS等的熟悉程度。但是，这些不会将await和?分成不同的操作，而Rust不会。 从await expr到expr.await也不是一件容易的事-这种变化并不像使用符印符号那样激进。 而且，由于上述的点功率，很可能通过键入expr.并将await作为自动完成弹出窗口中的第一个选项来学习.await 。

9. 印记易于编写，并提供良好的人体工程学设计。 但是，虽然.await键入时间更长，但它还带有点功率，可以使书写流程更好。 不必闯入let语句也有助于更好的人体工程学。 前缀await ，或者更糟糕的是await!(..) ，既缺乏点功能，也缺乏链接能力。 比较.await ， .await()和.await!() ，第一个提议最简洁。

由于没有一种语法最能同时实现所有目标，因此必须做出权衡。 对我而言，具有最大优势和最少缺陷的语法是.await 。 值得注意的是，它可以被链接，保留await作为关键字，可以抓握，具有点运算力，因此是可学习的和符合人体工程学的，具有明显的优先级，并且最终是可读的（尤其是具有良好的格式和突出显示）。

@Centril只是为了澄清一些问题。 首先，我只想确认您只想等待后缀，对吗？ 其次，如何处理.await作为字段访问的二元性？ 可以将.await为原样，还是应该使用带有括号的.await()来暗示那里正在发生某种操作？ 第三，使用.await语法，await是关键字还是只是“字段访问”标识符？

首先，我只想确认您只想等待后缀，对吗？

是的至少现在。

其次，如何处理.await作为字段访问的二元性？

这是一个小缺点。 点的力量有很大的上升空间。 我相信这种区别是用户会很快学到的，特别是因为它突出显示了关键字并且该结构将被频繁使用。 而且，正如Scott所指出的， .await?将是最常见的，这将进一步缓解这种情况。 就像我们已经说过fn一样，在rustdoc中为await添加一个新的关键字条目也应该很容易。

可以将.await为原样，还是应该使用带有括号的.await()来暗示那里正在发生某种操作？

我更喜欢.await没有尾巴() ; 在大多数情况下，结尾处有()似乎在大多数情况下都是不必要的盐，并且我猜想，这会使用户更倾向于寻找该方法。

第三，使用.await语法，await是关键字还是仅仅是“字段访问”标识符？

await仍然是关键字。 大概您将libsyntax更改await在.之后遇到await时不会出错，然后在AST中或降为HIR时以不同的方式表示它...但是这主要是实现细节。

感谢您清理所有内容！ 👍

此时，关键问题似乎是是否采用后缀语法。 如果那是方向，那么我们当然可以缩小范围。 阅读会议室，大多数postfix语法的支持者都会接受比前缀语法更合理的postfix语法。

进入此线程后缀语法似乎是失败者。 但是，它吸引了四名lang团队成员的明确支持和第五名的开放性（到目前为止，其他四名成员都保持沉默）。 另外，它还吸引了广大社区的大力支持。

而且，后缀语法的支持者似乎已经明确地认为这是Rust的最佳途径。 似乎有必要对迄今提出的论点提出一些深刻的问题或令人信服的反驳，以扭转这种支持。

鉴于此，似乎我们需要倾听@withoutboats的声音，他肯定一直在密切关注此主题，并听到其他四个lang团队成员的声音。 他们的观点可能会推动这一话题。 如果他们有顾虑，那么讨论这些将是优先事项。 如果他们确信后缀语法是正确的，那么我们可以继续寻求共识。

糟糕，只是注意到@Centril已发表评论，因此我将其帖子隐藏以保持整洁。

@ivandardi给定目标中的目标（1），我的理解是， loop {}永远不是结构文字表达式一样。 而且我希望它能被突出显示以使其更加明显（例如https://github.com/rust-lang/rust-enhanced/issues/333正在等待Sublime中的操作）。

我担心的是，在2015年版本的代码库中没有意识到的情况下，使await语法看起来像是一种不同的访问可能会引起混乱。 （2015年是未指定时的默认值，会打开其他人的项目，等等。）只要2015年版在没有await字段（并且有警告的情况下）时都存在明显错误，我认为（连同Centril的精彩论点）消除了我个人对关键字字段（或方法）的担心。

哦，我们在使用它时还应该决定的一件事是rustfmt如何最终对其进行格式化。

let val = await future;
let val = await returns_future();
let res = client.get("https://my_api").await send()?.await json()?;

1. 使用await -支票
2. 头等舱-检查
3. 链接-检查
4. 抓-检查
5. 非印章-检查
6. 优先顺序-¹检查
7. 点功率-²检查
8. 易于学习-³检查
9. 人机工程学-检查

¹优先顺序： await之后的空格使其在延后位置中不明显。 但是，它与以下代码完全相同： client.get("https://my_api").await_send()?.await_json()? 。 对于所有说英语的人来说，它比其他所有提案都更加自然。

²点电源：接下来键入. ， ?或;后，需要IDE的额外支持才能将await到方法调用的左侧。 似乎并不难实施

³易于学习：在前缀位置，程序员已经很熟悉。 处于稳定位置之后，语法稳定后就很明显

但是有关此语法的最强之处在于它将非常一致：

• 不能与属性访问混淆
• ?具有明显的优先级
• 它将始终具有相同的格式
• 它与人类语言相符
• 它不受方法调用链中变量水平出现的影响*

对于postfix变体，很难预测哪个函数是async ，水平轴上的下一个await出现在哪里：

let res = client.get("https://my_api")
    .very_long_method_name(param, param, param).await?
    .short().await?;

对于延迟变体，几乎总是一样的：

let res = client.get("https://my_api")
    .await very_long_method_name(param, param, param)?
    .await short()?;

不会有。 在等待和下一个方法调用之间？ 喜欢
get().await?.json() 。

2019年1月23日，星期三，05：06 I60R < [email protected]写道：

让val =等待未来；
let res = client.get（“ https：// my_api”）.await send（）?. await json（）?;

1. 使用等待-检查
2. 头等舱-检查
3. 链接-检查
4. 抓-检查
5. 非印章-检查
6. 优先顺序-¹检查
7. 点功率-²检查
8. 易于学习-³检查
9. 人机工程学-检查

---

¹优先顺序：空格使它在延后位置不明显。 但是它是
与以下代码完全相同：client.get（“ https：// my_api
“）.await_send（）?. await_json（）?。对于所有说英语的人来说，甚至更多
比其他所有提案自然

²点电源：可能需要IDE的额外支持才能将其移至
方法调用之后的左侧。 要么 ？ 接下来输入。 似乎也不是
难以实施

³易于学习：在前缀位置，程序员已经很熟悉了，
和递延位置也将是显而易见之后的语法是

稳定的

但是有关此语法的最强点是它将非常
一致的：

• 不能与属性访问混淆
• 它具有明显的优先级？
• 它将始终具有相同的格式
• 它与人类语言相符
• 在方法调用中不受水平变量的影响
  链*

*说明隐藏在扰流板下

使用postfix变体很难预测哪个函数是异步的，
水平轴上的下一次等待将出现在哪里：

让res = client.get（“ https：// my_api”）

.very_long_method_name(param, param, param).await?

.short().await?;

对于延迟变体，几乎总是一样的：

让res = client.get（“ https：// my_api”）

.await very_long_method_name(param, param, param)?

.await short()?;

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/rust-lang/rust/issues/57640#issuecomment-456693759 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AIA8Ogyjc8LW6teZnXyzOCo31-0GPohTks5vGAoDgaJpZM4aBlba
。

我们还应该决定rustfmt最终如何格式化它

那是https://github.com/rust-dev-tools/fmt-rfcs的域，所以我想说这是离题的。 我敢肯定，无论选择哪种修复性和优先级，都会有一些一致之处。

@ I60R

let res = client.get("https://my_api").await send()?.await json()?;

那如何寻找自由功能呢？ 如果我没看错，它实际上是前缀await 。

我认为这表明我们不应该那么快就抹杀C＃语言团队的经验。 微软在可用性研究上投入了很多精力，我们在这里基于一行代码来做出决定，并且前提是Rust足够特殊，可以具有与所有其他语言不同的语法。 我不同意这个前提-我在上面提到了LINQ和扩展方法在C＃中普遍存在。

但是，当.await不是表面语法时，尝试使用.aw可能不会发生，包括我自己在内。

〜我不认为其他语言的熟悉者会遇到这种情况。〜除此之外，您是否希望完成弹出窗口同时包含await和Future方法？

[...]我们在这里基于一行代码来做出决定，并且前提是Rust足够特殊，可以具有与所有其他语言不同的语法。 我不同意这个前提[...]

@lnicola我只是想指出一下，以防您和其他人错过它（在大量的评论中很容易错过）： https :

实际生产代码中的几个真实示例。

鉴于上面的@Centril的评论，似乎竞争最激烈的postfix选项是expr await postfix关键字语法和expr.await postfix字段语法（也许postfix方法语法还没有出来）。

与postfix关键字相比， @ Centril认为postfix字段受益于“点的力量”（IDE可能更好地将其建议为自动

相反， @ cramertj主张使用postfix关键字语法，因为该语法清楚表明它不是方法调用或字段访问。 @withoutboats认为postfix关键字是postfix选项中最熟悉的。

关于“点的力量”，我们应该考虑到IDE仍然可以在点之后提供await作为完成，然后在选择完成时将其删除。 足够聪明的IDE（例如带有RLS的IDE）甚至可以注意到Future，并在空格后提供await 。

与postfix关键字相比，由于模棱两可，postfix字段和方法选项似乎为异议提供了更大的表面积。 由于对postfix关键字的postfix字段/方法的某些支持似乎来自对方法链中存在空格的轻微不安，因此，我们应该查看@valff的意见，并与postval关键字（ foo.bar() await ）看起来不会比广义类型归属（ foo.bar() : Result<Vec<_>, _> ）令人惊讶。 对于这两者，在此间隔开的插曲之后，链接继续。

@ivandardi ， @lnicola ，

我已经用缺少免费函数调用的示例更新了我最近的评论。 如果您需要更多示例，可以参考我之前的评论中的最后一个破坏者

为了辩论future.await?与future await? ...

讨论不多的是方法链的可视化分组或grepping。

考虑（ match代替await突出显示语法）

post(url).multipart(form).send().match?.error_for_status()?.json().match?

相比于

post(url).multipart(form).send() match?.error_for_status()?.json() match?

当我目视扫描第一个链中的await我清楚而迅速地识别了send().await?并看到我们正在等待send() 。

但是，当我目视扫描第二条链中的await ，我首先看到await?.error_for_status()并且不得不走，不，备份，然后将send() await连接在一起。

是的，其中一些相同的参数适用于通用类型归类，但尚不被接受。 从某种意义上来说，尽管我喜欢键入归属，但我认为在_general_表达式上下文中（模糊，我知道），应该将其包装在括号中。 但是，这对于本次讨论来说都是题外话。 还请记住，代码库中的await数量具有很大的变化，即显着高于类型说明的数量。

通用类型归属还通过使用不同的运算符:将类型绑定到归属表达式。 就像其他二进制运算符一样，读取它可以使（视觉上）清楚地知道两个表达式是一棵树。 鉴于future await没有运算符，并且很容易被误认为future_await的习惯，因为很少会看到两个名称之间没有用运算符分隔，除非第一个是关键字（除非有例外，否则说我更喜欢前缀语法，但我不喜欢）。

如果愿意，可以将其与英语进行比较，其中使用连字符（ - ）直观地对单词进行分组，否则这些单词很容易被解释为单独的单词。

我认为这表明我们不应该那么快就抹杀C＃语言团队的经验。

我认为“这么快”和“信誉”在这里不公平。 我认为在这里发生的事情与异步/等待RFC本身发生的事情相同：仔细考虑为什么以一种方式完成，并找出平衡是否对我们来说是相同的。 C＃团队甚至在其中被明确提及：

• 第2394章真相大白
• 2394-async_await.md＃hot-async-functions

我认为await的想法是您实际上想要的是结果而不是未来
所以也许await语法应该更像'ref'语法

let future = task()
但
let await result = task()

所以要进行链接，您应该选择

task().chained_method(|future| { /* do something with future */ })

但

task().chained_method(|await result| { /* I've got the result */ })

- foo.await             // NOT a real field
- foo.await()           // NOT a real method
- foo.await!()          // NOT a real macro

它们都可以很好地与链接一起使用，并且都具有不是实际/方法/宏的缺点。
但是由于await作为关键字已经很特别，因此我们不需要使其更特别。
我们应该只选择最简单的foo.await 。 ()和!()在这里都是多余的。

@liigo

- foo await        // IS neither field/method/macro, 
                   // and clearly seen as awaited thing. May be easily chained. 
                   // Allow you to easily spot all async spots.

@mehcode

当我以可视方式扫描第一条链以等待时，我可以清楚快速地识别send（）。await？ 并看到我们正在等待send（）的结果。

我更喜欢间隔版本，因为更容易看到将来的构建位置和等待的位置。 恕我直言，更容易看到发生了什么

使用点分隔，看起来非常像方法调用。 突出显示代码不会有太大帮助，而且并非始终可用。

最后，我确实相信链接不是主要的用例（ ?除外，但foo await?尽可能清晰），并且

post(url).multipart(form).send().match?

与

post(url).multipart(form).send() match?

后者看起来更精简。

因此，如果我们确实缩小到future await和future.await ，我们是否可以使魔术“点”成为可选内容？ 这样人们就可以选择自己想要的一个，最重要的是，停止争论并继续前进！

拥有可选的语​​法没有害处，Rust有很多这样的例子。 最有名的是最后一个Sperator（ ;或,或其他，在最后一个项目之后，例如(A,B,) ）在大多数情况下都是可选的。 我没有看到为什么不能将点设为可选的强烈理由。

我认为现在是在Nightly进行此操作的好时机，让生态系统确定哪一个最适合他们。 我们可以用棉绒来强制使用首选样式，使其可自定义。

然后，在登陆Stable之前，我们会检查社区的使用情况，并决定我们应该选择其中一项，还是只保留两者。

我完全不同意宏对于该功能的感觉并不一流（一开始我不认为它是核心功能），并想再次强调我先前对await!()评论。 await!() （无论前缀还是后缀）都不是“真正的宏”，但我想最终有太多人希望尽快稳定此功能，而不是在后缀宏上阻止此功能，而前缀等待确实不是非常适合Rust。

无论如何，锁定此线程一天只能起到很大作用，我现在要退订。 如果您直接回答我的观点之一，请随意提及我。

我反对使用.语法的说法是await不是字段，因此它看起来不像字段。 即使使用语法高亮显示和粗体字体，它也将看起来像是某种特殊的字段，甚至自定义格式也不允许强调它不是字段，因为.后跟单词是与字段访问密切相关的。

也没有理由在.使用语法来实现更好的IDE集成，因为我们可以通过使用Intellij IDEA中提供的后缀补全.补全的任何不同语法。

我们需要将await视为控制流关键字。 如果我们强烈决定使用后缀await ，那么我们应该考虑不带.变体，我建议使用以下格式，以更好地强调可能出现中断的阻塞点：

async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true)
        await?.res.json::<UserResponse>()
        await?.user
        .into();
    Ok(user)
}

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()) 
    await? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key)
    await? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send()
    await?.error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()
    await?.error_for_status()?
    .json()
    await?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()
    await?.error_for_status()?
    .json()
    await?;

async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true)
        yield?.res.json::<UserResponse>()
        yield?.user
        .into();
    Ok(user)
}

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()) 
    yield? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key)
    yield? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send()
    yield?.error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()
    yield?.error_for_status()?
    .json()
    yield?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()
    yield?.error_for_status()?
    .json()
    yield?;

这也可能是@ivandardi有关格式化的观点的答案

我发现所有这些关于postfix的示例都比它更反对它。 漫长的等待链让人感到不对，应将链保留给将来的组合器。

比较（将match作为await来突出显示语法）：

post(url)?.multipart(form).send()?.match?.error_for_status()?.json().match?

至

let value = await post(url)?.multipart(form).send()?.error_for_status()
                 .and_then(|resp| resp.json()) // and then parse JSON

// now handle errors

注意到中间缺少等待吗？ 因为链接通常可以通过更好的API设计来解决。 如果send()返回带有其他方法的自定义Future，例如，将非200状态消息转换为硬错误，则无需额外等待。 现在，至少在reqwest中，它似乎就位运行并产生普通的Result而不是新的未来，这就是这里的问题所在。

在我看来，等待链接是一种强烈的代码味道，而.await或.await()会使很多新用户感到困惑，甚至不好笑。 .await尤其感觉像Python或PHP之外的东西，其中变量成员访问可以神奇地具有特殊的行为。

await应该是显而易见的，好像在说，“在继续之前，我们等待这个”而不是“然后，我们等待这个”。 后者实际上是and_then组合器。

考虑它的另一种潜在方法是将async / await表达式和期货视为迭代器。 他们都是懒惰的，可以有很多的状态，并能与语法被终止（ for-in的迭代， await期货）。 我们不会为迭代器提供语法扩展，以像我们在这里那样将它们链接在一起作为正则表达式，对吗？ 他们使用组合器进行链接，异步操作/功能也应这样做，仅终止一次。 效果很好。

最后，最重要的是，我希望能够垂直浏览一下函数的前几个缩进，并清楚地看到异步操作发生在哪里。 我的视野不是很好，等待在行尾或停留在中间会使事情变得更加困难，我可能会完全呆在原始期货上。

大家在发表评论之前，请先阅读此博客文章。

异步/等待与便利无关。 这与避免合并器无关。

这是关于启用组合器无法完成的新功能。

因此，任何有关“让我们使用组合器代替”的建议都是题外话，应在其他地方讨论。

注意到中间缺少等待吗？ 因为链接通常可以通过更好的API设计来解决。

在真正的异步示例中，您不会得到一个漂亮的链。 真实的例子：

req.into_body().concat2().and_then(move |chunk| {
    from_slice::<Update>(chunk.as_ref())
        .into_future()
        .map_err(|_| {
            ...
        })
        .and_then(|update| {
            ...
        })
        .and_then(move |(user, file_id, chat_id, message_id)| {
            do_thing(&file_id)
                .and_then(move |file| {
                    if some_cond {
                        Either::A(do_yet_another-thing.and_then(move |bytes| {
                            ...

                            if another_cond {
                                ...
                                Either::A(
                                    do_other_thing()
                                        .then(move |res| {
                                            ...
                                        }),
                                )
                            } else {
                                Either::B(future::ok(()))
                            }
                        }))
                    } else {
                        Either::B(future::ok(()))
                    }
                })
                .map_err(|e| {
                    ...
                })
        })
        // ...and here we unify both paths
        .map(|_| {
            Response::new(Body::empty())
        })
        .or_else(Ok)
})

组合器在这里没有帮助。 可以删除嵌套，但这并不容易（我尝试了两次但失败了）。 您最后有吨Either:A(Either:A(Either:A(...))) 。

OTOH可以通过async / await轻松解决。

@Pauan在完成我的帖子之前已经写了它。 随它吧。 不要提及组合器， async/await看起来不应该相似。 如果可以的话，还可以考虑更多重要的事情。

拒绝我的评论不会使组合器更方便。

仔细阅读类型归属注释，我在想如何将其与await结合使用。 考虑到有人使用.await或.await()作为保留的成员字段/方法访问的保留，我想知道是否可以使用通用的“ ascription”语法，（例如，“给我await返回”）。

将yield用于await进行语法突出显示

let result = connection.fetch("url"):yield?.collect_async():yield?;

结合类型说明，例如：

let result = connection.fetch("url") : yield?
    .collect_async() : yield Vec<u64>?;

优点：看起来仍然不错（IMHO），语法与字段/方法访问不同。
缺点：与类型归属（？）潜在冲突，理论上可能存在多个归属：

foo():yield:yield

编辑：在我看来，在合并的示例中使用2个归属会更合乎逻辑：

let result = connection.fetch("url") : yield?
    .collect_async() : yield : Vec<u64>?;

@Pauan过度应用该博客文章是不合适的。 组合符可以与await语法结合使用，以避免它描述的问题。

核心问题始终是，可产生的将来必须是'static ，但是如果您通过引用在这些组合器中捕获变量，则最终会得到不是'static的将来。 但是等待非'static未来并不会使您不在'static的异步。 因此，您可以执行以下操作：

锈
//切片：＆[T]

让x =等待future.and_then（| i |如果slice.contains（i）{async_fn（slice）}）;

因此，我原本打算完全不发表评论，但我想补充一些未编写大量异步代码但仍然必须阅读的人的注释：

• 前缀await很容易注意到。 这既是您期望的（在async fn内部）又是外部（在某些宏主体的表达式中）。
• 后缀await作为关键字可能在其他关键字很少甚至没有的情况下脱颖而出。 但是，一旦您与其他控制结构发生了闭包或类似操作，您的awaits就会变得不那么明显，并且更容易被忽略。
• 我发现.await作为伪字段非常奇怪。 在任何方面，对我而言，这都不像其他任何领域。
• 我不确定依靠IDE检测和语法突出显示是否是个好主意。 没有语法高亮显示时，易于阅读很有价值。 加上最近有关使语法复杂化及其对工具造成的问题的讨论，依靠IDE /编辑器正确处理可能不是一个好主意。

我不同意await!()作为宏“不会感到一流”的观点。 宏是Rust中完全一流的公民。 它们也不仅仅用于“发明用户代码中的语法”。 许多“内置”宏不是用户定义的，也不是仅出于语法原因而存在。 format!()可以为编译器提供静态类型检查格式字符串的功能。 include_bytes!()也不是用户定义的，也不是仅出于语法原因而存在，它是一个宏，因为它需要进行语法扩展，因为它再次在编译器内部执行特殊操作，并且不能合理地以任何其他方式编写，而无需将其添加为核心语言功能。

这就是我的观点：宏是一种以统一且毫不奇怪的方式引入和隐藏编译器魔术的完美

因此，我根本看不到需要特殊关键字。 就是说，如果它将成为关键字，那么应该仅仅是一个裸关键字–我真的不了解将其伪装成一个字段的动机。 这似乎是错误的，它不是字段访问，甚至不是像字段访问那样的远程访问（不像说用糖的getter / setter方法可能那样），因此将其视为一个字段与当今语言在语言中的工作方式不一致。

@ H2CO3 await!宏是每一种理想的方法，除了两个属性外，它都是好的：

1. 当您写又一千个等待时，多余的花括号确实很烦人。 出于相同的原因，Rust从if/while/...块中删除了括号。 看起来atm并不重要，但事实确实如此
2. async为关键字的不对称性。 异步应该做的事情不仅仅是在方法主体中允许一个宏。 否则，它可能只是函数顶部的#[async]属性。 我知道该属性不允许您在块等中使用它，但是它提供了遇到await关键字的一些期望。 这种期望可能是由其他语言的经验引起的，谁知道，但我坚信它的存在。 它可能没有解决，但必须加以考虑。

否则，它可能只是函数顶部的#[async]属性。

很长一段时间了，很抱歉看到它。 我们正在引入另一个关键字，而#[async]属性运行得很好，并且现在具有稳定的类似属性的过程宏，即使在语法和语义上，它甚至与其他语言都保持一致（并由编译器专门处理）。

@ H2CO3从用户角度看，将await作为宏的目的或优点是什么？ 是否有任何内置宏可以更改程序在后台的控制流？

@ I60R的优点是与其他语言的统一性，因此不必担心另一个关键字以及它带来的所有

我看不出为什么第二部分很重要–不能有一个内置的宏可以执行新操作吗？ 实际上，我认为几乎每个内置宏都会产生一些“怪异”的事情，如果没有编译器的支持就无法（合理/有效/如此）实现。 在这方面， await!()不会是一个新的入侵者。

我之前曾建议隐式等待，最近又建议不可链接的等待。

社区似乎非常支持明确的等待（我很乐意对此进行更改，但是……）。 但是，显式粒度是创建样板的原因（即，在同一表达式中多次使用它似乎会创建样板）。

[警告：以下建议会引起争议，但请给予真诚的机会]

我很好奇大多数社区是否会妥协并允许“部分隐式等待”？ 也许每个表达式链的显式阅读等待一次？

await response = client.get("https://my_api").send()?.json()?;

这类似于价值重构，我称之为表达重构。

// Value de-structuring
let (a, b, c) = ...;

// De-sugars to:
let _abc = ...;
let a = _abc.0;
let b = _abc.1;
let c = _abc.2;

// Expression de-structuring
await response = client.get("https://my_api").send()?.json()?;

// De-sugards to:
// Using: prefix await with explicit precedence
// Since send() and json() return impl Future but ? does not expect a Future, de-structure the expression between those sub-expressions.
let response = await (client.get("https://my_api").send());
let response = await (response?.json());
let response = response?;



md5-eeacf588eb86592ac280cf8c372ef434



```rust
// If needed, given that the compiler knows these expressions creating a, b are independent,
// each of the expressions would be de-structured independently.
await (a, b) = (
    client.get("https://my_api_a").send()?.json()?,
    client.get("https://my_api_b").send()?.json()?,
);
// De-sugars to:
// Not using await syntax like the other examples since await can't currently let us do concurrent polling.
let a: impl Future = client.get("https://my_api_a").send();
let b: impl Future = client.get("https://my_api_b").send();
let (a, b) = (a.poll(), b.poll());
// return if either a or b is NotReady;

let a: impl Future = a?.json();
let b: impl Future = b?.json();
let (a, b) = (a.poll(), b.poll());
// return if either a or b is NotReady;
let (a, b) = (a?, b?);

我也对核心思想的其他实现感到满意，“每个表达链读一次等待就足够明确了”。 因为它减少了样板，但也使链接成为可能，这是每个人都最熟悉的基于前缀的语法。

@yazaddaruvala上面有一个警告

我很好奇大多数社区是否会妥协并允许“部分隐式等待”？ 也许每个表达式链的显式阅读等待一次？

1. 我认为大多数社区都不需要部分隐式的东西。 Rust本机方法更像是“充分利用一切”。 甚至强制转换u8-> u32都可以完成。
2. 它不适用于更复杂的场景。 编译器应如何处理Vec<Future> ？

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

是否应为每个嵌套调用执行await ？ 好的，我们可能可以使一行代码的等待工作（因此不会等待嵌套的mapFunc ），但是打破这种行为太容易了。 如果等待对一条代码行有效，则任何重构（例如“提取值”）都会破坏它。

@yazaddaruvala

我是否理解您正确的意图是使用前缀? wait优先于

这意味着以下这三个语句是等效的：

// foo.bar() -> Result<impl Future<_>, _>>
let a = await foo.bar()?;
let a = await (foo.bar()?);
await a = foo.bar()?;

并且以下两个语句是等效的：

// foo.bar() -> impl Future<Result<_, _>>
await a = foo.bar()?;
let a = await (foo.bar())?;

我不确定语法是否理想，但是也许具有更改为“等待隐式上下文”的关键字会使前缀关键字的问题减少。 同时，允许在需要时使用更精细的控制来控制等待位置。

在我看来，简短的单行前缀等待具有与许多其他编程语言和许多人类语言相似的好处。 如果最后决定只将await作为后缀，我希望有时我会使用Await!()宏（或任何与关键字不冲突的类似形式），当我觉得根深蒂固地熟悉英语句子结构将有助于减少阅读/编写代码的精力。 对于较长的链式表达式，后缀形式具有确定的价值，但是我明确地不基于客观事实的观点是，由于人为的前缀等待复杂性由口语提供补贴，仅具有一种形式的简单好处就可以了。没有明显超过两者的潜在代码清晰度。 假设您相信程序员至少可以选择最适合当前代码块的那个。

@Pzixel

我认为大多数社区都不需要部分隐式的东西。 Rust本机方法更像是“充分利用一切”。

我不一样。 我看到它始终是显式和隐式的折衷。 例如：

• 在功能范围内需要变量类型
  
  
  
  • 变量的类型可以在局部范围内隐含。
  
  
  • Clousure上下文是隐式的
  
  
  • 鉴于我们已经可以对局部变量进行推理了。
  
  
• 需要生命周期来帮助借阅检查器。
  
  
  
  • 但是可以在本地范围内进行推断。
  
  
  • 在功能级别上，当它们都是相同的值时，不需要显式地指定生命周期。
  
  
• 我敢肯定还有更多。

每个表达式/语句仅使用await ，并具有链接的所有优点，这是在显式样板和精简样板之间做出非常合理的折衷。

它不适用于更复杂的场景。 编译器应如何处理Vec？

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

我认为编译器应该出错。 存在巨大的类型差异，无法推断。 同时，此线程中的任何语法都无法解决带有Vec<impl Future>的示例。

// Given that json() returns a Vec<imple Future>,
// do I use .await on the `Vec`? That seems odd.
// Given that the client.get() returns an `impl Future`,
// do I .await inside the .map? That wont work, given Iterator methods are not `async`
client.get("https://my_api").send().await?.json()[UNCLEAR]?.parse_as::<Vec<String>>()?.map(|x| client.get(x)[UNCLEAR])?;

我认为Vec<impl Future>是一个不好的例子，否则我们应该将所有建议的语法都保持在相同的标准下。 同时，“部分-隐含的await”语法我建议工程比更复杂的场景，如目前的提议await (a, b) = (client.get("a")?, client.get("b")?);使用正常的后缀或前缀的await let (a, b) = (client.get("a") await?, client.get("b") await?);结果在连续的网络操作，其中部分隐式版本可以通过编译器适当地并发运行（如我在原始帖子中所示）。

早在2011年，当C＃中的async功能仍在测试中时，我询问await是前缀运算符，并从C＃语言PM中得到了答复。 既然讨论了Rust是否应该使用前缀运算符，所以我认为在此处发布该响应可能很有价值。 来自为什么“ await”是前缀运算符而不是后缀运算符？ ：

正如您可以想象的那样，在我们确定现在存在的内容之前，等待表达式的语法是一个非常重要的讨论：-)。 但是，我们对后缀运算符的考虑并不多。 关于postfix的某些内容（请参阅HP计算器和Forth编程语言）使原则上更简单，实践中更难于理解或理解。 也许这只是数学符号洗净我们小时候的方式...

我们肯定发现前缀运算符（具有其命令性的味道-“做到这一点！”）到目前为止是最直观的。 我们大多数的一元运算符已经是前缀，并且等待似乎与之匹配。 是的，它淹没在复杂的表达式中，但是评估顺序通常也是如此，因为例如函数应用程序也不是后缀。 首先评估参数（在右侧），然后调用函数（在左侧）。 是的，C＃中的函数应用程序语法已经内置了括号，这是有区别的，而在等待时通常可以删除它们。

我在await中大致看到的（并且被我自己采纳的）是一种使用大量临时变量的样式。 我倾向于

var bResult = await A().BAsync();
var dResult = await bResult.C().DAsync();
dResult.E()

或类似的东西。 通常，我通常会避免在最简单的表达式之外的所有表达式中都等待一个以上的等待（即它们都是同一函数或运算符的参数；它们可能很好），并且我会避免在等待表达式中加上括号，宁愿对这两个作业都使用额外的局部变量。

说得通？

Mads Torgersen，C＃语言PM

我作为C＃开发人员的个人经验是，语法促使我使用这种样式的多条语句，这使得异步代码的读写比同步等效代码笨拙得多。

@yazaddaruvala

我不一样。 我看到它始终是显式和隐式的折衷

它仍然是明确的。 我可以链接有关btw的好文章。

我认为编译器应该出错。 存在巨大的类型差异，无法推断。 同时，以Vec为例不能通过该线程中的任何语法解决。

为什么错误呢？ 我很高兴拥有Vec<impl future> ，然后我可以一起加入。 您无缘无故地提出了额外的限制。

我认为Vec这是一个很差的例子，否则我们应该使所有提议的语法都遵循相同的标准。

我们应该检查每一种情况。 我们不能仅仅忽略边缘情况，因为“嗯，无论如何，没人会写这个”。 语言设计主要是关于边缘情况。

@chescock我同意您的(await FooAsync()).Bar() 。 但是在Rust中，您可以。 我说的是? 。 在C＃中，您具有通过异步调用传播的隐式异常。 但是在锈病中，您必须明确一些，并在等待结果后在函数结果上写入? 。

当然，你可以要求用户写

let foo = await bar();
let bar = await foo?.baz();
let bar = bar?;

但是比这更奇怪

let foo = await? bar();
let bar = await? foo.baz();

这看起来好多了，但是需要引入await和? doint (await expr)? 。 而且，如果我们还有其他一些运算符，我们可以编写await?&@#并使所有组合完全起作用...看起来有点复杂。

但是然后我们可以将await作为后缀，它将自然适合当前语言：

let foo = bar() await?;
let bar = foo.baz() await?;

现在， await?是两个分开的令牌，但它们可以一起使用。 您可以拥有await?&@#并且不必担心将其侵入编译器本身。

当然，它看起来比前缀方式更奇怪，但是可以说，这全都与Rust / C＃的区别有关。 我们可能会使用C＃的经验来确保我们需要显式的等待语法，该语法可能具有单独的关键字，但是我们不应该盲目地遵循相同的方式而忽略Rust / C＃的差异。

我很早就支持使用前缀await ，甚至邀请C＃语言开发人员加入该主题（因此我们提供的信息比2011😄更新了），但现在我认为该后缀await关键字是最好的方法。

别忘了每天晚上，所以如果我们找到更好的方法，我们可以稍后再做。

在我看来，结合以下各项，我们可能能够同时兼顾两个方面：

• 前缀async关键字
• 一般的postfix宏功能

两者在一起将允许实现后缀.await!()宏而无需编译器魔术。

现在，后缀.await!()宏将需要编译器魔术。 但是，如果稳定了await关键字的前缀变体，则将不再是这样：后缀.await!()宏可以简单地实现为以其参数（表达式）为前缀的宏使用await关键字并将所有内容括在方括号中。

这种方法的优点：

• 前缀await关键字可用，并且熟悉其他语言的用户也可以使用。
• 可以在需要使表达式的异步特性“脱颖而出”的地方使用前缀async关键字。
• 将有一个postfix变体.await!() ，该变体可用于链接情况或前缀语法不方便的任何其他情况。
• 对于postfix变体，不需要（可能是意外的）编译器魔术（否则，对于postfix字段，方法或宏选项将是一个问题）。
• Postfix宏也可用于其他情况（例如.or_else!(continue) ），出于类似的原因，它们偶然碰巧需要postfix宏语法（否则，它们需要以尴尬且难以理解的方式包装前面的表达式）。
• 前缀await关键字可以相对快速地稳定下来（允许开发生态系统），而不必等待后缀宏的实现。 但是从中长期来看，我们仍然会等待后缀语法的出现。

@ nicoburns ， @ H2CO3 ，

我们不应该将await!()和.or_else!(continue)类的控制流运算符实现为宏，因为从用户的角度来看，没有有意义的理由这样做。 无论如何，在这两种形式下，用户将具有完全相同的功能，并且应该学习这两种功能，但是，如果将这些功能实现为宏，则用户将担心为什么要以这种方式实现它们。 不可能不注意到这一点，因为常规的一流操作符与实现为宏的常规操作符之间仅存在奇异和人为的区别（因为宏本身是一流的，但它们所实现的不是）。

这是完全一样的答案，作为额外的.之前await ：我们并不需要它。 宏不能模仿一流的控制流：它们具有不同的形式，具有不同的用例，具有不同的突出显示，它们以不同的方式工作，并且它们完全不同。

对于.await!()和.or_else!(continue)功能，都存在一种正确且符合人体工程学的解决方案，具有漂亮的语法： await关键字和none -coalescing运算符。 我们应该更喜欢实现它们，而不是通用的，很少使用的，看起来像后缀宏的丑陋的东西。

没有理由使用宏，因为没有像format!()这样复杂的东西，没有像include_bytes!()这样很少使用的东西，没有定制的DSL，没有消除用户代码中的重复项，不需要类似vararg的语法，就不需要外观有所不同，我们不能仅因为有可能就使用这种方式。

我们不应该将控制流运算符实现为宏，因为从用户的角度来看，没有有意义的理由这样做。

try!()被实现为宏。 有一个很好的理由。

我已经描述了使await成为宏的原因–如果现有功能也可以实现目标，则不需要新的语言元素。

没有像format!()这样复杂的东西

我希望有所不同： format!()与复杂性无关，而与编译时检查有关。 如果不是用于编译时检查，则可能是一个函数。

顺便说一句，我不建议它应该是一个后缀宏。 （我认为不应该。）

对于这两个功能，都存在具有优美语法的适当且符合人体工程学的解决方案

我们不应该为每个函数调用，流控制表达式或次要便利功能提供其自己的非常特殊的语法。 这只会导致语言膨胀，毫无理由地充满语法，这与“美丽”恰恰相反。

（我已经说了我能做的；我将不再回答这个问题。）

@nicoburns

在我看来，结合以下各项，我们可能能够同时兼顾两个方面：

• 前缀await关键字
• 一般的postfix宏功能

这需要使await成为上下文关键字，而不是当前的真实关键字。 我不认为我们应该这样做。

两者一起可以实现后缀.await!()宏，而无需编译器魔术。

这是比foo await或foo.await （尤其是后者）更复杂的解决方案实施方式。 仍然有很多“魔术”。 您刚刚进行了会计核算。

这种方法的优点：

• 前缀await关键字可用，并且熟悉其他语言的用户也可以使用。

如果以后要添加.await!() ，我们只是给用户更多的知识（ await foo和foo.await!() ），现在用户会问“我应该使用哪个什么时候..”。 与单个解决方案相比，这似乎比foo await或foo.await消耗了更多的复杂性预算。

• Postfix宏也可用于其他情况（例如.or_else!(continue) ），由于类似的原因，它们偶然碰巧需要postfix宏语法（否则，它们需要以尴尬且难以理解的方式包装前面的表达式）。

我相信后缀宏具有价值，应该添加到语言中。 但这并不意味着它们需要用于await ing； 如您所述，在.or_else!(continue)和许多其他地方，后缀宏将很有用。

• 前缀await关键字可以相对快速地稳定下来（允许开发生态系统），而不必等待后缀宏的实现。 但是从中长期来看，我们仍然会等待后缀语法的出现。

我认为“留下开放的可能性”没有任何价值。 后缀对组合，IDE体验等的价值今天众所周知。 我对“今天稳定await foo并希望我们明天就foo.await!()达成共识”不感兴趣。

@ H2CO3

try!()被实现为宏。 有一个很好的理由。

try!(..)已弃用，这意味着我们认为它不适合该语言，尤其是因为它不是后缀。 用它作为参数（除了不应该做的事情之外）似乎很奇怪。 而且， try!(..)的定义没有编译器的任何支持。

顺便说一句，我不建议它应该是一个后缀宏。 （我认为不应该。）

await并不是“每个人都..”-特别是，它不是次要的便利功能； 相反，这是要添加的主要语言功能。

@phaylon

加上最近有关使语法复杂化及其对工具造成的问题的讨论，依靠IDE /编辑器正确处理可能不是一个好主意。

语法foo.await旨在减少工具方面的问题，因为任何对Rust都有良好支持的编辑器都已经可以理解.ident形式。 编辑者需要做的只是将await到关键字列表中。 而且，好的IDE已经具有基于.代码完成功能-因此，当用户键入.时，扩展RLS（或等效项...）以提供await作为第一个建议似乎更简单。 .后my_future 。

至于语法的复杂化， .await实际上最不可能使语法复杂化，因为语法中支持.await本质上是解析.$ident ，然后在ident == keywords::Await.name()上不出错

语法foo.await旨在减少工具问题，因为任何对Rust都有良好支持的编辑器都已经可以理解.ident格式。 编辑者需要做的就是将await添加到关键字列表中。 而且，好的IDE已经具有基于的代码完成。 -因此，当用户键入时，扩展RLS（或等效项...）以提供await作为第一建议似乎更简单。 在my_future之后。

我只是发现这与语法讨论不符。 问题不仅仅在于现在，还在于几版之后的5年，10年，20年。 但是，正如我希望您注意到的那样，我也建议即使突出显示一个关键字，如果涉及到其他关键字，等待点也会被忽略。

至于语法的复杂化，.await实际上最不可能使语法复杂化，因为在语法中支持.await本质上是解析。$ ident，然后在ident == keyword :: Await.name（）上不会出错。

我认为荣誉属于await!(future) ，因为语法已经完全支持它。

@Centril try!最终变得多余，因为?运算符可以严格执行更多操作。 这不是“不适合该语言”。 但是，您可能不喜欢它，但我接受。 但是对我来说，这实际上是Rust发明的最好的东西之一，也是卖点之一。 而且我知道它是在没有编译器支持的情况下实现的，但是在讨论它是否执行控制流程时，我看不到它的意义。 不管。

等待不是“每一个..”

但是这里提到的其他内容（例如or_else ）是，我的观点仍然适用于主要功能。 仅出于添加语法的目的而添加语法并不是优势，因此，只要在更一般的情况下已有某些东西已经起作用，就应该优先于发明新的表示法。 （我知道反对宏的另一种说法是“它们不是后缀”。我根本不认为，等待成为其自己的后缀运算符的好处足以证明其成本是合理的。我们在嵌套函数调用中幸免于难。在编写了几个嵌套宏之后，效果会一样好。）

在2019年1月23日，星期三，09：59：36PM + 0000，Mazdak Farrokhzad写道：

• Postfix宏也可用于其他情况（例如.or_else!(continue) ），出于类似的原因，它们偶然碰巧需要postfix宏语法（否则，它们需要以尴尬且难以理解的方式包装前面的表达式）。

我相信后缀宏具有价值，应该添加到语言中。 但这并不意味着它们需要用于await ing； 如您所述，在.or_else!(continue)和许多其他地方，后缀宏将很有用。

使用.await!()主要原因是看起来像一个宏
很明显，它会影响控制流。

.await看起来像字段访问， .await()看起来像函数
调用，字段访问和函数调用都不会影响控制
流。 .await!()看起来像一个宏，并且宏会影响控制
流。

@joshtriplett我在标准意义上不影响控制流。 这是证明借位检查程序应按定义的期货运行的基本事实（而pin则是推理方式）。 从本地函数执行的角度来看，执行等待就像大多数其他函数调用一样。 您从上次中断的地方继续，并在堆栈上有一个返回值。

我只是发现这与语法讨论不符。 问题不仅仅在于现在，还在于几版之后的5年，10年，20年。

我不知道你这是什么意思。

我认为荣誉属于await!(future) ，因为语法已经完全支持它。

我理解，但是在这一点上，由于该语法还有许多其他缺点，我认为它已被有效排除。

@Centril try!最终变得多余，因为?运算符可以严格执行更多操作。 这不是“不适合该语言”。 但是，您可能不喜欢它，但我接受。

它已明显过时，并且在Rust 2018上写入try!(expr)也是一个硬错误。我们共同决定这样做，因此被认为不适合。

使用.await!()主要原因是看起来像一个宏可以清楚地表明它会影响控制流。

.await看起来像字段访问， .await()看起来像函数调用，并且字段访问和函数调用都不会影响控制流。

我相信，区别是用户会相对容易地学习到的东西，尤其是.await通常后面跟着? （这是函数局部控制流）。 至于函数调用，如上所述，我认为可以说迭代器方法是控制流的一种形式。 此外，仅仅因为一个宏可以影响控制流，并不意味着它会这么做。 许多宏都没有（例如dbg! ， format! ，...）。 的理解，即.await!()或.await将影响控制流量（寿比弱得多的感? ，按照@HeroicKatora注）从单词流动await本身。

@Centril

这需要使上下文关键字与当前的真实关键字相反。 我不认为我们应该这样做。

真是的那有点痛苦。 也许宏可以使用不同的名称，例如.wait!()或.awaited!() （后者非常好，因为它清楚地表明它适用于前面的表达式）。

“这两者在一起将允许实现后缀.await！（）宏而无需编译器魔术。”
这是比foo await或foo.await（尤其是后者）更复杂的解决方案实现方式。 仍然有很多“魔术”。 您刚刚进行了会计操作。

而且，try！（..）的定义没有编译器的任何支持。

如果我们有一个前缀await关键字和后缀宏，那么在没有编译器支持的情况下也可以实现.await!() （也许名称不同），对吗？ 当然， await关键字本身仍会带来大量的编译器魔术，但这仅适用于宏的结果，与try!()与return关键字。

如果以后要添加.await！（），我们只是给用户更多的知识（await foo和foo.await！（）），现在用户会问“何时使用..”。 与单个解决方案相比，这似乎比foo await或foo.await占用了更多的复杂性预算。

我认为这增加了用户的复杂性是最小的（实现复杂性可能是另一回事，但是如果我们仍然想要后缀宏...）。 两种形式都可以直观地阅读，因此在阅读其中任何一种时，都应该清楚正在发生的事情。 至于编写代码时要选择的内容，文档可以简单地说：

“等待Rust的未来有两种方法： await foo.bar();和foo.bar().await!() 。使用这是一种样式偏好，对执行流程没有影响。”

我认为“留下开放的可能性”没有任何价值。 后缀对组合，IDE体验等的价值今天众所周知。

那是真实的。 我想我想更多的是确保我们的实现不会阻止将来使用更加统一的语言的可能性。

我不知道你这是什么意思。

没关系。 但是总的来说，当语法明显但没有突出显示时，我也更喜欢它。 因此，在git diff和其他此类上下文中，事情显得突出。

理论上是的，对于琐碎的程序是，但是实际上程序员
需要知道他们的暂停点在哪里。

举一个简单的例子，您可以将RefCell保留在一个悬浮点上，然后
您的程序的行为与RefCell是
在暂停点之前释放。 在大型程序中
这样的无数微妙之处在于当前功能
暂停是重要的信息。

2019年1月23日，星期三，2：21 PM HeroicKatora [email protected]
写道：

@joshtriplett https://github.com/joshtriplett我不影响控制
标准意义上的流量。 这是证明
借方检查程序应按定义在期货中运行。 从这个角度来看
本地函数执行，等待执行就像其他任何函数调用一样。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/rust-lang/rust/issues/57640#issuecomment-456989262 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABGmeqcr2g4olxQhH9Fb9r6g3XRaFUu2ks5vGOBkgaJpZM4aBlba
。

在2019年1月23日，星期三，00-08：02：26：07 PM，Mazdak Farrokhzad写道：

使用.await!()主要原因是看起来像一个宏可以清楚地表明它会影响控制流。

.await看起来像字段访问， .await()看起来像函数调用，并且字段访问和函数调用都不会影响控制流。

我相信区别是用户将相对容易学习的东西

他们为什么要这么做？

我相信区别是用户会相对容易地学习到的东西，尤其是.await通常会跟在后面吗？ （这是功能局部控制流）。

通常是，但并非总是如此，并且语法绝对适用于并非如此的情况。

至于函数调用，如上所述，我认为可以说迭代器方法是控制流的一种形式。

与return或? （甚至break ）的方式不同。 这将是非常惊人的，如果一个函数调用可以在两个水平恢复起来了调用它的功能（的原因，锈没有例外之一正是因为这是令人惊讶的），或在调用破环了功能。

而且，仅仅因为宏会影响控制流并不意味着它会这样做。 许多宏都没有（例如dbg！，format！，...）。 .await！（）或.await的理解将影响控制流（根据@HeroicKatora的注释，其含义比？弱得多）来自于await本身。

我一点都不喜欢。 影响控制流是非常重要的副作用。 它应该具有通常无法执行的语法格式。 在Rust中可以做到这一点的构造有：关键字（ return ， break ， continue ），运算符（ ? ）和宏（通过求一个其他形式）。 为什么通过添加例外来使水变得浑浊？

@ejmahler我不认为与普通函数调用相比，持有RefCell有何不同。 内部函数也可能想要获取相同的RefCell。 但是似乎没有一个主要问题是不能立即掌握全部潜在的调用图。 同样，堆栈耗尽问题也无需特别注意，您必须注释提供的堆栈空间。 这里的比较将有利于协程！ 如果未内联常规函数调用，是否应该使它们更加可见？ 我们是否需要显式的尾部调用来解决图书馆日益棘手的问题？

答案是，恕我直言，使用RefCell并等待时最大的风险是不熟悉。 当上面的其他问题可以从硬件中抽象出来时，我确实相信，作为程序员，我们也可以学会在屈服点上不保留RefCell等，除非经过审查。

Elliott Mahler在2019年1月23日星期三晚上10:30:10 PM +0000写道：

理论上是的，对于琐碎的程序是，但是实际上程序员
需要知道他们的暂停点在哪里。

：+1：

@HeroicKatora

一个关键的区别是您必须检查多少代码，多少代码
您必须考虑的可能性。 程序员已经习惯了
确保他们调用的所有内容都不使用已检查的RefCell
出来。 但是等待着，我们没有检查单个调用堆栈，而是没有
控制在等待期间执行的内容-实际上是
程序可能已运行。 我的直觉告诉我，一般的程序员是
因为他们没有足够的能力来应对这种可能性的爆炸式增长
不必频繁地处理它。

在游戏中，悬停点是关键信息的另一个示例
编程，我们通常会编写要恢复的协程
每帧一次，我们在每次简历上更改游戏状态。 如果我们忽略了
这些协程之一中的暂停点，我们可能会使游戏陷入困境
多个帧的状态。

所有这些都可以通过说“变得更聪明，更少做些”来解决。
错误”，但从历史上看，这种方法行不通。

在2019年1月23日星期三下午2:44 Josh Triplett [email protected]
写道：

Elliott Mahler在2019年1月23日星期三晚上10:30:10 PM +0000写道：

理论上是的，对于琐碎的程序是，但是实际上程序员
需要知道他们的暂停点在哪里。

：+1：

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/rust-lang/rust/issues/57640#issuecomment-456995913 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABGmep05nhZizdE5xil4FsnpONJCxqn-ks5vGOXhgaJpZM4aBlba
。

再举一个关键点，即暂停点是关键信息，在游戏编程中，我们通常编写协程，以便每帧恢复一次，并在每次恢复时更改游戏状态。 如果我们忽略了其中一个协程中的暂停点，则可能会使游戏在多帧状态下处于破裂状态。

如果将密钥放在SlotMap上，则会泄漏内存。 语言本身并不能帮助您解决此问题。 我想说的是，您关于等待的方式的示例模糊不清（只要它是一个关键字，它的出现将是唯一的）似乎并不能推广到其他功能尚未发生的问题。 我认为您应该减少对语言立即提供给您的功能的评价，而应更多地考虑如何使您能够表达自己的功能。 评估您的工具，然后应用它们。 建议一种游戏状态的解决方案，以及如何很好地解决该问题：编写一个包装程序，该包装程序在返回时断言游戏状态实际上已达到要求的数量，异步允许您为此原因借用您自己的状态。 在该分隔的代码中禁止其他人等待。

RefCell中的状态爆炸不是来自您未检查是否未在其他地方使用过它，而是来自其他代码点，这些代码点不知道您依赖于该不变量并将其静默添加。 这些以相同的方式处理，包括文档，注释和正确的包装。

阻塞io时，持有RefCell与暂存Mutex并没有太大区别。 您可能会遇到死锁，这比紧急情况更糟，更难调试。 但是，我们不使用显式的block关键字注释阻塞操作。 :)

在异步函数之间共享RefCell将大大限制它们的一般可用性（ !Send ），因此我认为这并不常见。 通常应避免使用RefCell ，并且在使用时尽可能短地借用。

因此，我认为在收益点上意外地暂存RefCell并不重要。

如果我们忽略了其中一个协程中的暂停点，则可能会使游戏在多帧状态下处于破裂状态。

协程和异步函数是另一回事。 我们不是要使yield隐式。

对于任何支持宏语法而不是关键字语法的人，请在此处进行说明：请描述它与await含义，这意味着它应该是一个宏，以及与_could_具有的while有何不同只是一个while!宏（即使仅使用macro_rules! ；也没有任何特殊框）。

编辑：这不是修辞。 我对这种事情真的很感兴趣，就像我以为我想运行到第一次等待（就像C＃）一样，但是RFC还是说服了我。

对于任何支持宏语法而不是关键字语法的人，请在这里：请描述await的含义，这意味着它应该是一个宏，以及它与（while）的区别（可能只有一段时间了）！ 宏（甚至只使用macro_rules！；根本没有特殊框）。

我大部分都同意这种推理，并且我确实想使用关键字作为前缀语法。

但是，如上所述（https://github.com/rust-lang/rust/issues/57640#issuecomment-456990831），我支持在postfix语法中也使用postfix宏（也许.awaited!()以避免名称与prefix关键字冲突）。 我的部分原因是，拥有只能以一种方式使用的关键字会使事情变得更简单，并且为宏保存了进一步的变体，但据我所知，主要是，没有人能够提出后缀我认为可以接受的关键字语法：

• foo.bar().await技术上讲， foo.bar().await()是关键字，但是它们看起来像是字段访问或方法调用，我不认为这样的控制流修改结构应该被隐藏。
• foo.bar() await只是令人困惑，尤其是与进一步的链接（例如foo.bar() await.qux() 。 我从未见过像这样的后缀用作关键字（我敢肯定它们存在，但实际上我想不出任何一种我所知道的语言都可以像这样工作的示例）。 而且我认为它的理解非常混乱，好像等待适用于qux()而不是foo.bar() 。
• foo.bar()@await或其他一些标点符号也可以使用。 但这不是特别好，而且感觉很特别。 我实际上认为此语法没有任何重大问题（与上述选项不同）。 我只是觉得，一旦我们开始添加sigils，那么平衡就开始朝着放弃自定义语法，而朝着成为宏的方向发展。

我将再次重申较早的想法，尽管经过了新的思想和考虑因素的调整，然后尝试保持沉默。

await作为关键字仅在async函数内有效，因此我们应该在其他地方允许标识符await 。 如果在外部作用域中将变量命名为await ，则除非将其用作原始标识符，否则无法从async块内对其进行访问。 或者，例如， await!宏。

此外，像这样修改关键字可以满足我的要点：我们应该允许生成器和异步函数的混合和匹配，如下所示：

// imaginary generator syntax stolen from JavaScript
fn* my_generator() -> T {
    yield some_value;

    // explicit return statements are only included to 
    // make it clear the generator/async functions are finished.
    return another_value;
}

// `await` keyword would not be allowed here, but the `yield` keyword is
#[async]
fn* my_async_generator() -> Result<T, E> {
    let item = some_op().await!()?; // uses the `.await!()` macro
    // which would really just use `yield` internally, but with the pinning API
    // same as the current nightly macro.

    yield future::ok(item.clone());

    return Ok(item);
}

// `yield` would not be allowed here, but the `await` keyword is.
async fn regular_async() -> Result<T, E> {
   let some_op = async || { /*...*/ };

   let item = await? some_op();

   return Ok(item);
}

我相信对于想做时髦东西的极其高级的用户来说，这是足够透明的，但允许新手和中级用户仅使用必要的东西。 2和3（如果不带任何yield语句使用）实际上是相同的。

我还认为前缀await?是将?到异步操作结果中的简便快捷方式，但这并不是绝对必要的。

如果postfix宏成为官方的东西（我希望他们会这样做），则await!(...)和.await!()可以并存，从而针对特定的用例和样式允许三种等效的等待方式。 我认为这不会增加任何认知开销，但会提供更大的灵活性。

理想情况下， async fn和#[async] fn*甚至可以共享用于将基础生成器转换为异步状态机的实现代码。

这些问题已经清楚地表明，没有一种真正的首选样式，因此我所能期望的最好是提供干净，灵活，易读且易于接近的复杂性级别。 我认为上述方案是对未来的一个很好的妥协。

await作为关键字无论如何仅在async函数内有效，因此我们应该让标识符在其他地方等待。

考虑到卫生宏，我不知道在Rust中是否可行。 如果我把foo!(x.await)或foo!(await { x })当它想的expr ，我想应该是明确的是， await关键字是想-不是await字段或带有字段init简写的await结构体文字表达式-甚至在同步方法中。

允许三种等效的等待方式

请不。 （至少在core 。显然，如果需要，人们可以在自己的代码中创建宏。）

现在，后缀.await！（）宏将需要编译器魔术。 但是，如果稳定了await关键字的前缀变体，那么它将不再成立：postfix .await！（）宏可以简单地实现为以await关键字为参数（表达式）加上前缀并包装的宏括号中的所有内容。

我会注意到这同样正确-但更容易！ -从另一个方向来看：如果我们稳定.await关键字语法，那么人们如果已经足够不喜欢后缀，就可以制作一个awaited!()前缀宏。

我不喜欢添加多个允许的变体（例如前缀和后缀）的想法，但是出于与用户要求略有不同的原因。 我在一家相当大的公司工作，并且为代码风格而战是真实的。 我只想使用一种显而易见的正确形式。 毕竟，就这一点而言，Python的Zen可能是正确的。

我不喜欢添加多个允许的变体（例如前缀和后缀）的想法，但是出于与用户要求略有不同的原因。 我在一家相当大的公司工作，并且为代码风格而战是真实的。 我只想使用一种显而易见的正确形式。 毕竟，就这一点而言，Python的Zen可能是正确的。

我明白你的意思。 但是，没有办法阻止程序员定义自己的宏来执行诸如await!()类的事情。 类似的结构永远是可能的。 因此，无论如何，确实会有不同的变体。

好吧，至少不要await!(...) ，因为那样会出错。 但是如果用户定义了macro_rules! wait { ($e:expr) => { e.await }; } ，然后将其用作wait!(expr)那么看起来就很独特，并且可能很快就会过时。 这大大降低了生态系统发生变化的可能性，并允许用户学习更少的样式。 因此，我认为@yasammez的观点是恰当的。

@Centril如果有人想做坏事，他们几乎不会停止。 _await!()或awai!()呢？

或者，当启用unicode标识符时，类似àwait!() 。

...

@earthengine的目标是设定社区规范（类似于我们对样式棉绒和rustfmt所做的工作），而不是防止各种人故意做怪异的事情。 我们在这里处理概率，而不是绝对保证不出现_await!() 。

让我们总结并检查每种后缀语法的参数：

• __ expr await （postfix关键字）__：Postfix关键字语法使用我们已经保留的await关键字。 等待是一个神奇的转变，使用关键字可以使它突出。 它看起来并不像字段访问，方法或宏调用，并且我们不必将其解释为例外。 它非常适合当前的解析规则和?运算符。 可以说，方法链接中的空间不会比通用类型Ascription差，这似乎是某种形式的RFC。 不利的一面是，IDE可能需要做更多的事情才能为await提供自动补全功能。 人们可能会发现方法链接中的空间太麻烦了（尽管@withoutboats认为这可能是一个优势），特别是如果代码的格式没有使await结束每一行。 它使用一个关键字，如果采用另一种方法，也许我们可以避免使用该关键字。

• __ expr.await （后缀字段）__：后缀字段语法利用了“点的力量” -看起来和感觉上很自然，并且允许IDE自动完成await而无需执行其他操作（例如如自动删除点）。 就像后缀关键字一样简洁。 在await前面的点可能会使使用grep查找它的实例更容易。 不利的一面是现场访问。 作为一种明显的现场访问方式，没有视觉上的暗示“这可以做某事”。

• __ expr.await() （后缀方法）__：后缀方法的语法类似于后缀字段。 从好的方面来说， ()调用语法向读者表明“这可以做些事情”。 从本地来看，这await的魔术行为伪装为一种方法可能会造成混淆。 我们可以说await是一种方法，在有限的意义上，Scheme中的call/cc是一个函数。 作为一种方法，我们需要考虑Future::await(expr)是否应与UFCS保持一致。

• __ expr.await!() （后缀宏）__：后缀宏语法类似地利用“点的力量”。 宏! bang表示“这可能会做一些魔术。” 不利的一面是，它甚至更嘈杂，而宏虽然具有魔力，但它们通常不会像await那样对周围的代码产生魔力。 不利的一面是，假设我们对通用后缀宏语法进行了标准化，那么继续将await作为关键字可能会出现问题。

• __ expr@ ， expr# ， expr~和其他单字符符号__：与我们使用?一样使用单个字符可以使简洁性最大化，并且可能使后缀语法看起来更自然。 与? ，我们可能会发现，如果await开始遍及我们的代码，我们将非常感谢您的简洁。 不利的一面是，除非而且直到用await乱码的麻烦成为问题为止，否则很难就采用这种语法所固有的权衡取舍达成共识。

我想发表一个帖子，对@traviscross的这些摘要帖子表示感谢！ 它们一直都写得很好并且交联得很好。 非常感谢。 ：心：

我有一个想法，就是像F＃这样添加“管道运算符”，然后用户可以使用前缀或后缀（具有明显的语法差异）。

// use `|>` for instance, Rust can choose other sigils if there are conflicts with current syntax
await expr
expr |> await

// and we can use this operator on normal function calls too
f(g(h(x))) 
x |> h |> g |> f
// this is more convenient than "postfix macro"
x.h!().g!().f!()