Hoping for clarity on how Rust works in these situations (programming.dev)

submitted 10 months ago by nerdblood@programming.dev to c/rust@programming.dev

12 comments fedilink hide all child comments

I'm slowly starting Rust for Rustaceans, and it's already poking holes in my understanding of Rust. Here's a couple initial questions I have:

A shared reference, &T is , as the name implies, a pointer that may be shared. Any number of references may exist to the same value, and each shared reference is Copy, so you can trivially make more of them

I don't understand why a shared reference has to implement copy. In fact, isn't this not true just by the fact that references work for Strings and Strings size can't be known at compile time?

I'm having trouble with the idea of assigning a new value to a mutable reference.

let mut x = Box::new(42); *x = 84;

Why in this example, is the assignment dereferenced. Why not just do x=84? is it dereferenced specifically because is Boxed on the heap?

you are viewing a single comment's thread
view the rest of the comments

[-] snaggen@programming.dev 10 points 10 months ago* (last edited 10 months ago)

A reference &T holds a pointer, ie. the memory adress to the actual content of T

So, in the example x doesn't hold the value 42, it holds the memory adress to the memory there the integer value 42 is stored. So, to access the value, you need to dereference the reference. Which is why you need to use *x when you assign the value.

[-] snaggen@programming.dev 6 points 10 months ago

And the Copy question.It is not that s reference has to implement Copy. A reference IS Copy, by the simple fact that it is a primitive value on the stack.

[-] KillTheMule@programming.dev 9 points 10 months ago* (last edited 10 months ago)

A reference IS Copy, by the simple fact that it is a primitive value on the stack.

This seems a bit misleading, noting that unique/mutable references aren't Copy. Shared references are Copy because it's sound to have that, and it's a huge QOL improvement over the alternative.

[-] Miaou@jlai.lu 2 points 10 months ago

In this context mutability is part of the type signatures. &T and &mut T are two different types, the former implements copy but not the later. It's not really an "exception" in the type system.

[-] Anders429@programming.dev 1 points 10 months ago

I wouldn't say it's misleading. The question was specifically about shared references, it seemed obvious to me that's what they were referring to in their answer.

[-] KillTheMule@programming.dev 2 points 10 months ago

The question was specifically about shared references

Sure, but the way I read the answer was "All primitive values on the stack are Copy", which isn't true (my example being mutable references, which have the same representation as shared ones, "just" a different semantic meaning). That's what I meant by misleading.

load more comments (2 replies)

this post was submitted on 22 Oct 2023

17 points (94.7% liked)

Rust

5744 readers

84 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

kahnclusions@programming.dev

torcherist@programming.dev