我已经学到了很多技巧，可以在不使用unsafe的情况下“摆脱” Rust的限制。例如：
Option::unwrap RefCell 我可能还会忘记其他人。
在这种情况下，对正确性的特定方面的责任从编译器转移到了程序员。那些本应是编译错误的事情变得很恐慌，程序员应该只是“知道他们的逻辑是正确的”。
Panic优于内存破坏，但是考虑到Rust的品牌是一种完全安全的语言，我认为这些“陷阱门”将以某种方式被正式识别-在类型系统，文档或其他方面-以便于识别。程序员应该知道何时使用快捷方式并承担额外的责任。
是否存在这种区别？甚至只是文档中某处的明确列表？我的思维模式是否错误，使这种事情变得不必要了？
答案 0 :(得分：6)
不，没有正式的区别。
我相信您是在问是否有effect system。尽管编译器开发人员已经讨论了一段时间，但是从长远来看，这是否真正有益还是没有共识。
“摆脱” Rust的限制
这些“绕开”什么都没有。这些方法本身可以确保满足要求。
从编译器转移到程序员
我不同意这种评估。职责已从 compile （编译）时间更改为 run（运行）时间，但是编译器和库代码仍确保维护安全性。
使用
unsafe
不安全的代码确实将责任转移给了程序员。但是，该程序员将构建其他程序员可以使用的安全抽象。理想情况下，他们使用在编译时检查的工具来构建抽象，从而有助于减少运行时错误。
Rust的品牌是一种完全安全的语言
正确性方面的责任
是的，Rust打算成为一种内存安全语言，这并不意味着用Rust编写的代码是正确的。品牌强调记忆安全性；其他人则认为这意味着“无法崩溃”之类的事情，但我们无法防止所有错误的解释。
另请参阅：