我的 C++ 背景让我对内部可变性感到不舒服。下面的代码是我围绕这个主题的调查。
我同意，从借用检查器的角度来看，处理每个内部状态可能迟早改变的单个结构上的许多引用是不可能的；这显然是内部可变性可以提供帮助的地方。
此外，在第15.5章“RefCell 和内部可变性模式”中锈病编程语言，有关的例子Messenger特质及其对实施
MockMessenger结构让我觉得，这是一种常见的API设计，系统地喜欢&self过&mut self，即使它很明显，迟早会强制要求某种可变性。Messenger发送消息时如何实现不改变其内部状态？例外只是打印消息，这与 一致&self，但一般情况可能包括写入某种内部流，这可能意味着缓冲，更新错误标志......所有这些当然都需要&mut self，例如
impl Write for File.
依靠内部的可变性来解决这个问题听起来好像是，在C ++中，const_cast荷兰国际集团或滥用mutable成员只是因为在申请的其他地方，我们是不是一致
const岬（对于C ++的学习者常犯的错误）。
所以，回到我下面的示例代码，我应该：
&mut self（编译器不会抱怨，即使它不是强制性的）从change_e()到change_i()为了与我改变存储的整数值的事实保持一致？&self，因为内部可变性允许它，即使我实际上改变了存储的整数的值？这个决定不仅对结构本身来说是局部的，而且会对使用这个结构的应用程序中可以表达的内容产生很大的影响。第二种解决方案肯定会有很大帮助，因为只涉及共享引用，但它是否与 Rust 中的预期一致。
我在Rust API Guidelines 中找不到这个问题的答案 。是否有任何其他类似于C++CoreGuidelines 的Rust 文档 ？
/*
$ rustc int_mut.rs && ./int_mut …