17
What Rust calls "reference" is a much more specific thing, that is not so general-purpose. (users.rust-lang.org)
submitted 5 months ago by maegul@lemmy.ml to c/learningrustandlemmy@lemmy.ml
12 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments
[-] Jayjader@jlai.lu 2 points 5 months ago

Ahh, that makes a ton more sense to me! Thanks.

I like your verbiage regarding "things you do" vs "an [ambient] set of constraints", and I would go one further (or in any case my mental model is): there are a set of valid states or configurations for references that is smaller than (and contained within) the set of possible or imaginable configurations.

By configuration, here, I kinda literally mean "the state of the program/machine executing the program, as that execution plays out". So, "3 read-only borrows of some piece of data" is a valid configuration, while "2 simultaneous mutable borrows" is an invalid state for the program to be in. It's sort of the same conceptual approach as types: you express the valid/allowed configurations that are (almost always) a subset of the overall possible states. Except in this case, it's the language that has defined it once, ahead of time, rather than us programmers who define things as we go. Maybe that just gets us back to the same point that wasn't originally clicking for you, though.

Sidenote: I wonder if a language could be developed that allowed the programmer to define or setup their own set of constraints around lifetimes and references. Sort of like what Zig seems to allow for memory allocator/allocation strategies, but specifically for ownership semantics. As I type this out, I can't shake the feeling that this is basically what Rust has already done with their & vs &mut vs Box vs RC vs RefCell etc. It's not like there is a way to safely have 2 mutable references to the same memory/variable that is both general and simpler than existing mechanisms.

Re: lifetime notations, it's good to know that this helped you. For me it was the combination of encountering the particular part in chap 4 of The Book where they examine the case of a function that accepts a tuple and returns a ref to the first element (or something along those lines), and trying to define (and then use) a struct that would store a ref to some other data in a hobby project.

Overall, this makes me realize how much of Rust I have already internalized!

[-] maegul@lemmy.ml 1 points 5 months ago

Sidenote: I wonder if a language could be developed that allowed the programmer to define or setup their own set of constraints around lifetimes and references. Sort of like what Zig seems to allow for memory allocator/allocation strategies, but specifically for ownership semantics. As I type this out, I can’t shake the feeling that this is basically what Rust has already done with their & vs &mut vs Box vs RC vs RefCell etc.

Yep to all of your post ... and this is my impression too (without having gotten on top of the smart pointers yet).

Only thing I can imagine adding though would be an optional garbage collector (that is shipped in the binary like with Go). I'm not sure how helpful one would be beyond RC/RefCell (I'd imagine a good GC could handle a complex network of references better, which wouldn't be very "rust"-like, but expanding the scope of the language toward "just getting stuff done" territory would be the main point of a GC). A quick search turned up this project which seems to be very small but still active (interestingly, the blog post linked there points out that rust used to have a built in GC but removed it to be a 3rd party library instead).

Re: lifetime notations, it’s good to know that this helped you. For me it was the combination of encountering the particular part in chap 4 of The Book where they examine the case of a function that accepts a tuple and returns a ref to the first element (or something along those lines), and trying to define (and then use) a struct that would store a ref to some other data in a hobby project.

Yea for me the structure and framing of The Book when lifetimes were first brought up (in Ch 4) didn't work for me as it came off to me as another series of problems to solve or constraints to navigate.

What I find interesting and compelling about the framing in my top post is that it conceptualises references and borrowing by starting with lifetimes. I'm not as experienced as you and haven't internalised rust like you have (awesome to read though!), but I think I would have found it better to go from the basic idea of pointers as a way of not taking ownership and then going straight into "everything has a lifetime with changing permissions/locks over that time depending on what other references exist and while rust infers these lifetime durations sometimes, sufficient complexity requires you to specify them yourself" and then building out from that basis. For instance, I'm not even sure The Book makes it clear that Rust is inferring variable lifetimes automatically (??).

[-] Jayjader@jlai.lu 2 points 5 months ago

I was reading this last evening and ultimately decide against pinging you with it at the time, lol.

It directly riffs off of, and complements, the article you posted. It also speaks to your remarks on an optional garbage collector, as well as "how to think about the lifetime/borrow checker/permissions interplay".

but I think I would have found it better to go from the basic idea of pointers as a way of not taking ownership

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".

I suspect Rust is so complex, and like a living organism its parts have co-evolved together so much, that there is no linear explanation or introduction that can "truly" do it justice. You sort of have to throw yourself in, and repeat that process from a handful of directions/trajectories, to start to get a cohesive idea of the whole. I say "co-evolved" notably because so much of "modern" Rust seems to me to be syntactic sugar over "core/original/2015" rust.

I haven't gotten to the chapters on explicit lifetime annotation this time around, but I expect The Book to clearly state, then, that everything has a lifetime and the compiler actually infers most of them for you as part of this "syntactic sugar".

[-] maegul@lemmy.ml 1 points 5 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!

this post was submitted on 28 May 2024
17 points (100.0% liked)

Learning Rust and Lemmy

231 readers
1 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.

Running Projects

Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
  4. This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

See also:

Rules

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities

Thumbnail and banner generated by ChatGPT.

founded 9 months ago
MODERATORS
maegul@lemmy.ml
sorrybookbroke@sh.itjust.works
Jayjader@jlai.lu