为什么Rust要求提前返回，而不是最后返回？

Question

为什么允许在末尾隐式返回，但提前返回需要

return

关键字？

fn bar() -> u64 {
    if true { 1 }
    else { 0 }
}

这在语义上是等价的，但会引发错误，Rust 抱怨我应该使用

return 1;

来代替。

fn foo() -> u64 {
    if true { 1 } // early return is an error
    0
}

我看不出这不起作用的技术原因，编译器显然能够检测到这一点，并且（隐式）返回语句只是语法糖。 有什么理由不允许隐性提前回报吗？

---

为什么编译器要求我在此处添加 return 语句？ 和 问答解释了为什么该示例当前是错误的：

在 Rust 中，完整的语句必须具有类型 () rodrigo

return x 也是一个表达式 - 它的计算结果只是从不，因此可以在任何地方使用而不会出现类型不匹配的情况Cerberus

我正在寻找为什么做出这种设计选择的答案。

Answer 1

您提出的问题是事实的结果，Rust（主要）是一种基于表达式的语言。正如 Rust 参考 中所述：

Rust 主要是一种表达语言。这意味着大多数形式的产生价值或产生效果的评估都是由表达式的统一语法类别指导的。每种类型的表达式通常可以嵌套在另一种类型的表达式中，并且表达式求值的规则涉及指定表达式生成的值以及其子表达式本身求值的顺序。

相比之下，语句主要用于包含并显式排序表达式求值。

因为大多数在其他语言中是语句的东西在 Rust 中都是表达式（例如

if-else

块）。

另一个不成文的规则是 Rust 是明确的。正如 cdhowie 在评论中指出的那样，这是一件非常好的事情。在您提供的示例中，编译器可以猜测您想要提前返回，这通常不是正确的猜测。然而，即使在这个简单的例子中，这种猜测也不能保证“永远”正确。在一些更复杂的示例中，编译器保守地假设它无法确定用户想要什么。 第三个参数是前一个参数的扩展，是提前返回（以及

break

和

continue

）

打破函数/循环的正常控制流程

。因此我们必须明确地标记它。否则可能会导致函数控制流程的混乱。 总而言之，Rust 要求提前返回明确标记为：

遵守表达规则

• 保守，不要冒险
猜测
• 错误 明确打破函数流程，这有助于读者推理代码。