Borrowing std::cell::Cell issue

1

Trying to solve my issue of I have a ‘collection of boxed terminal commands’, but now need local result from one command for another I still run into the problem of returning the function that contains the local std::cell::Cell references.

Rust playground

I can't seem to find a solution to this and start to wander if this is the correct approach at all.

3

Temporary loans (&) are views into data already stored elsewhere. You can't create any new data in a function and return it as a temporary loan, because that data won't be stored permanently anywhere, and & forbids storing it. Local variables are always destroyed when a function exits, and Rust can't make them live any longer:

let x = Cell::new(PathBuf::new()); 
AddInt::new(&x)

In this case x is a local variable, and variables will always be destroyed before the function returns. This means that &x can never be returned, and it's impossible to use &x for anything that must survive this function call. It's just a wrong design to have references like that. & is not the right tool for this job. Don't put temporary references in structs: in 99% of cases struct Something<'a> doesn't do what inexperienced Rust users assume, and it's a design error.

If you want to have a shared reference to data that you can create later, then Rc/Arc is the correct type for it. No &, no lifetimes. You could use Rc<Path> or Arc<Path> to efficiently store paths that can be shared without being restricted to a temporary scope (note that it's Rc<Path>, not Rc<&'a Path> — the data is owned and stored, not borrowed).
If you need to mutate them in-place, then Rc<RefCell<PathBuf>>> or Arc<Mutex<PathBuf>>> will work too. You could also use plain PathBuf if each node could have its own path.

5 Likes
4

I'm at a loss how to use Rc...

Rust Playground

5

Your playground with Rc compiles and runs...what are you questions about Rc?

1 Like
6

How to store the path, mutate it in one method and then use it in another of which both methods need to be collected and fired off later.

7

That's not very specific and seems unrelated to your playground. Are you actually asking why the path is empty in the output of your playground? If so, it's because you've called take on the path below which replaces the path with a default empty value. Does this change help?:

                println!("path: {:?}", self.path);
                // println!("path: {}", self.path.take().display());

This has nothing to do with Rc.

1 Like
8

I thought take() would simply return the wrapped value, not return a default empty value.

Your line returns an empty refcell.
Rust Playground

9

The output is:

path: RefCell { value: "" }

That is an empty PathBuf inside the RefCell. At the point you print it, you haven't changed the path.

Here is a simpler example.

1 Like
10

A better answer is to say that the borrow and borrow_mut methods are the way you access the value inside a RefCell.

The following code has a mistake that is worth understanding:

impl Calculate for AddInt {
    fn calculate(&mut self) -> Answer {
        self.retain = Rc::new(RefCell::new(PathBuf::from("/etc")));
        Answer::I32(self.lhs + self.rhs)
    }
}

What this does is replace the original shared Rc (and its contents) with a different new Rc. That means the original Rc is no longer shared here. Does that make sense?

This doc has an overview of RefCell.

The contents of an Rc, on the other hand, are accessed via dereferencing, which normally happens automatically. You can call methods and access fields of the contents, without any special syntax. This doc has an overview of Rc.

1 Like
11

It's unclear to me what you want to do with the paths (I don't know what your program is doing).

Shared references are used to have one value that can be reused across many object, and possibly mutated from many different places, with result of the mutation visible from all places at once.

But you seem to want to create a new PathBuf every time, and it's never shared. If you keep using Rc::new every time, then the Rc is pointless , because it always has only one user. Rc must be cloned to take advantage of the sharing.

If you just want a different path for every object, then use PathBuf and nothing else. No Rc, no RefCell, no & loans. The most basic simplest PathBuf directly.

2 Likes
12

I was shooting in the dark with Rc and RefCell.
It's all new to me.
I've figured it out now thanks to your and @jumpnbrownweasel's help.

Rust Playground

And it's still unclear to me how this works.
I thought cloning would create a new object?
So how does the mutation retain from one object to the other?

13

Cloning a referenced counted pointer (Rc or Arc) will only increment its reference count. The term "clone" still applies because each cloned value can be used independently.

https://doc.rust-lang.org/std/rc/index.html

The type Rc<T> provides shared ownership of a value of type T, allocated in the heap. Invoking clone on Rc produces a new pointer to the same allocation in the heap. When the last Rc pointer to a given allocation is destroyed, the value stored in that allocation (often referred to as “inner value”) is also dropped.

2 Likes