问题标签 [interior-mutability]

I'm trying to wrap my head around Rc and RefCell in Rust. What I'm trying to achieve is to to have multiple mutable references to the same objects.

I came up with this dummy code:

The most interesting part is this:

I change the name of Freds mother and then print out the name of Susan which should happen to be exactly the same reference. And surprise, surprise it prints out "Susana" so I am assuming that my little experiment of having shared mutable references was successful.

However, now I wanted to mutate it again this time accessing it as the partner of John which should also happen to be exactly the same instance.

Unfortunately when I comment in the following two lines:

I'm running into my old friend cannot move out of dereference of&-pointer. What am I doing wrong here?

我有一个具有内部可变性的结构。

产生错误：

问题是我不能有一个Foo返回借用的函数vec，因为借用vec只在 的生命周期内有效Ref，但Ref立即超出范围。

我认为Ref必须坚持下去，因为：

RefCell<T>使用 Rust 的生命周期来实现“动态借用”，这是一个可以声明对内部值的临时、独占、可变访问的过程。s 的借用RefCell<T>是在“运行时”跟踪的，这与 Rust 的本地引用类型不同，后者在编译时完全静态跟踪。因为RefCell<T>借用是动态的，所以可以尝试借用一个已经可变借用的值；当这种情况发生时，它会导致任务恐慌。

现在我可以写一个这样的函数来返回整个内部：

MutableInterior.hide_me但是，这可能会将真正私有的实现细节的字段（在此示例中）暴露给Foo.

理想情况下，我只想公开它vec本身，可能有一个守卫来实现动态借用行为。然后来电者不必了解hide_me。

我有一个RefCell<HashMap>并且想借表，找到一个键，并返回一个对结果的引用：

（操场）

如果我删除RefCell然后一切正常：

在不复制哈希表中的字符串的情况下编写查找函数的正确方法是什么？

什么时候需要使用Cell 或 RefCell？似乎有许多其他类型的选择可以代替这些，并且文档警告说使用RefCell是一个“最后的手段”。

使用这些类型是“代码气味”吗？谁能举一个例子，说明使用这些类型比使用其他类型更有意义，例如Rcor Box？

如果我理解正确，则不可能在 Rust 中通过a创建可变借用std::rc::Rc，您必须使用Cellor RefCell。但无论如何我无法理解如何使用它们。例如考虑这个简单的例子：

我收到以下错误：

但是，如果我从行中删除引用（并更新类型mutx）：

一切都很好。但我不明白为什么，因为RefMut::deref_mut() -> &mut T在第 16 行调用的尊重应该&&mut T在第一种情况下返回，而&mut T在第二种情况下。但是由于编译器应该*根据需要应用许多（如果我知道deref coercionRefMut<X>::deref_mut()是如何工作的），和之间应该没有区别RefMut<&X>::deref_mut()

编辑：错误地我忘了mut在第 15 行写，因为在链接的例子中是正确的。所以现在是let mut mutx...

我正在学习 Rust 并尝试编写双向链表。但是，我已经陷入了典型的迭代遍历实现中。我的印象是借用检查器/删除检查器过于严格，当它从RefCell. 我需要重复设置一个变量绑定（curr在这种情况下）来借用它的当前内容：

编译器抱怨：

没有 NLL

使用 NLL

我真的很感激这个问题的迭代解决方案（非递归）。

如果我们运行它，那么我们会正确地得到错误“无法分配给不可变字段a.x”。

如果我们删除这两个//注释，并注释掉这个坏行，那么我们会得到错误“无法分配给&引用中的数据”。这是有道理的，因为&mut不提供内部可变性。我们可以&A自由地重新借用，所以这不能提供可变访问，ala&&mut是&&.

如果我们同时删除//注释和/* */注释，那么整个事情都会编译，允许违反我们的不变量的坏行a.x永远不能指向其他任何东西。

应该如何维护这个x不可更改的不变量？我们可以在提供公共解引用方法的同时将字段设为私有，除了A不可接受的为 in 编写构造函数。

我们可以通过创建A一个包装器的私有成员来避免令人讨厌的构造函数，该包装器struct AA(A)本身承载公共解引用方法。现在AA需要一个简单的构造函数，但它不需要所有字段的参数A，不影响执行顺序等。如果我们需要为两者实现一些特征，这将变得很A痛苦AA。

然而，另一种方法是通过使用内部可变性Cell<A>，使用Cell::replace，然后再放回去。这听起来很有问题，但表明存在更多解决方案。

任何更清洁的方法？

我正在尝试创建一个方法，该方法返回一个迭代器，该迭代器的值HashMap被装箱在 a 内RefCell，但是我遇到了一个错误，即Ref返回的RefCell::borrow 时间不够长，无法从方法返回迭代器。这是我的代码：

编译错误：

如何在不破坏封装的情况下返回对 RefCell 内某些内容的引用？建议创建一个守卫，它封装Ref并提供一个用于访问底层值的接口，但我需要做的是返回一个Values<'a, K, V>已经封装了对 a 的普通引用的迭代器对象 () HashMap。

我的主要问题是我有一个运行时跟踪引用Ref<T>，而我需要一个普通引用来创建迭代器。Ref::map公开了一个简单的映射引用，但它要求映射器函数返回另一个引用，这在此处是不可能的。我应该重做整个迭代器功能以使用Ref还是有更好的方法？

为什么这个程序无法编译

它给出了信息：

例如给出这段代码：

如何防止LibraryData在外部发生变异LibraryStruct？LibraryStruct应该是唯一能够data在其方法中发生变异的人。这是可能的Rc<RefCell<LibraryData>>还是有替代方案？请注意，我正在编写“库”代码，以便可以更改它。