Rust 语法中既然已经包含 while 了，那为什么还要有一个专门的 loop 语法来实现无限循环呢，为什么不使用 while true 呢？这是因为 Rust 选择了简易的 流敏感分析（flow-sensitive analyses） 方式，编译器不会在编译期确定 while 后面表达式的结果。因此你会发现，针对如下代码：

// 堆代码 duidaima.com
fn why_use_loop() -> i32 {
    let mut start = 1;
    while true {
        if start > 5 {
            return start;
        }
        start += 1;
    }
}

尽管我们知道逻辑上它总是会返回 i32 类型，但由于 Rust 编译器并不分析表达式 true 的结果（尽管它显而易见），故而它会认为 while 结束后的代码仍会被执行。此例中后续无其它代码了，因此会返回 () 。

也许你会觉得可以将 while true 整体作为特殊情况进行静态分析，这样便能省去 loop 关键字。但这显然违背语言在设计上的一致性，再说了，如果 while 后面是值为 true 的静态常量又该如何处理呢？所以 Rust 选择了用 loop 来明确告诉编译器编码者的意图，而不是用 while true 。

当然，如若你满足了 Rust 的编译要求，给上面的例子以类型匹配的返回值，while true 在逻辑上也未尝不可执行：

fn why_use_loop() -> i32 {
    let mut start = 1;
    while true {
        if start > 5 {
            return start;
        }
        start += 1;
    }
    -1  // 注意这里返回了 i32 类型
}

编译器选择对你的执着给予警告：

这其中似乎有些无奈，毕竟依照 Rust 的语言规范 while true 确实不能算作语法错误，但既然它已提供了 loop ，while true 自然显得与语法预期有些格格不入。我们也可以从上面的错误信息中看到，编译器默认选择了 #[warn(while_true)] 的 atrribute 。也许你执意想使用 while true 又不愿看到这一警告，Rust 为你提供了 #[allow(while_true)] ；也许你无法容忍这种不一致性，Rust 同样为你提供了 #[deny(while_true)] ，此时代码将无法编译通过：