• 免责声明：如前所述，确切的推理可能很难理解;然而，我们可以看看事实。

在我看来，这样更安全。
不会的。
恐慌不会引入内存或线程不安全，也不是可以忽略的错误信号方法。
绝对安全
此外，它将统一两个函数的返回类型。
是的。这是一件喜忧参半的事。
引用爱默生的话：
愚蠢的一致性是狭隘思想的恶魔
请记住，在Rust中，Result不能被忽略，它必须被承认和处理。这在一定程度上降低了快捷方式的价值。比较：

let h = Builder::new().spawn(f).unwrap();

let h = spawn(f).unwrap();

let h = spawn(f);

字符串
后者更像是一条捷径！
在这种特殊情况下，“默认恐慌”背后的动机是什么？

方便。

线程API是围绕两个互补的API构建的：

• Builder API提供了对每个方面的细粒度控制，但代价是冗长，
• 免费函数API提供了一种快速生成线程的简洁方法，但代价是控制。

这样，无论您想要控制还是简洁，都有一个标准的API适合您。
不这样做的 * 代价 * 是，许多人会在默认情况下引入unwrap函数。每个人都有自己的函数。而且很难跳到项目中。

Rust在“out of resources”（资源不足）时会出现恐慌，比如OOM。在这种情况下，“can't create thread”（无法创建线程）错误一定是指硬件或软件资源不足（参见pthread_create errors）。技术上还有其他错误，但是看看暴露的API，我会说你不能从安全的Rust代码中访问它们，我假设Windows错误非常相似。escape hatch允许您干净地尝试一些操作并检查是否成功。对于堆分配，这目前意味着您需要使用unstable APIs，但这些正在改进（截至2017年7月11日已经在夜间），并且很可能在未来稳定下来。