Perpetual n00b struggling with ownership (again)
users.rust-lang.org
Other languages use term "reference" for storing things "by reference" or just referencing any object anywhere in general. It's not like that in Rust. What Rust calls "reference" is a much more specific thing, that is no so general-purpose. It has a narrower, restrictive usage. Rust references are more like read-only or write-exclusive locks. They make their target unmovable and immutable for entire duration of their existence. They can't exist on their own, only as a counterpart of an owned va...

A nice comment in a forum thread (extracted below, but also see the shorter more facetious version below that) about references and their lifetimes in structs. Here is a link to the full thread over on users.rust-lang.org

I feel like I needed to hear or read this, and I feel like this sort of clarification is not put front and centre enough in rust learning material (as others in the thread say too). "The Book" certainly doesn't seem interested in clarifying perspectives like this.

The Comment

Other languages use term "reference" for storing things "by reference" or just referencing any object anywhere in general. It's not like that in Rust.

What Rust calls "reference" is a much more specific thing, that is no so general-purpose. It has a narrower, restrictive usage. Rust references are more like read-only or write-exclusive locks. They make their target unmovable and immutable for entire duration of their existence. They can't exist on their own, only as a counterpart of an owned value.

References in structs also make the whole struct itself temporary, and everything that touches that struct becomes temporary and tied to the scope of the borrowed value that started it.

If these restrictions (that cause you fight with the borrow checker) aren't what you want to achieve, then you don't want temporary references.

99% of the time when you need to store something "by reference", Box (or Arc or String or PathBuf or Vec or some other owned type) is the right answer.

Note that &T and Box<T> have identical representation in memory — a pointer. They differ by ownership.

In Short

From here

You're not allowed to use references in structs until you think Rust is easy. They're the evil-hardmode of Rust that will ruin your day.

😉

Use Box or Arc to store things in structs "by reference". Temporary borrows don't do what you think they do.

  • maegul (he/they)@lemmy.mlM
    ·
    4 months ago

    Thanks for the link! Will try to read it.

    small quibble: String, Box, and Vec are all technically pointers that do take ownership (rather, they have ownership of what they’re pointing to). It’s really only “references” in Rust that don’t take ownership. Which, IIRC, is more or less how The Book introduces references in chap 4. So I’m not really sure how what you’re describing would differ from the current state of the book. Nonetheless, I understand the confusion that comes from “learning about” lifetimes so “late”.

    Yea, I was going to specify (lol) that my first time through I really missed or didn't focus on what Box and Vec were as possibly alternative tools to references or at least interesting objects in terms of combining ownership and pointers to data on the heap ... and how I'm not sure that's really on me given the order of ideas in The Book and the emphasis on references. Again, for me right now, it seems that "lifetimes" is the connecting concept in that it clarifies what's going on and what problems are being solved/created. For me, instead of the section in Ch 4, it was an early section in the Rustonomicon (that I was just casually browsing through ... I know nothing about unsafe rust) that leaned in hard on the centrality of lifetimes.

    Nonetheless, I'm a little keen now to get a grip on how a Box (or other owning + pointing type) can be used as an easier/cleaner substitute for references. I don't have a clear image in my mind and I think I just need some application to work with or example to read through (maybe in the blog post you linked).

    Thanks again for the link!