Rust

5981 readers

51 users here now

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

Wormhole

[email protected]

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

[email protected]

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

submitted 1 year ago by [email protected] to c/[email protected]

5 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

[–] [email protected] 1 points 1 year ago

The key thing to understand is that in Rust, references are considered unique types. This means that &T is a separate type from T.

So, for #1, it is not saying that T implements Copy, it is saying that regardless of what T is, &T implements Copy. This is because, by definition, it is always valid to copy a shared reference, even if T itself is not Copy.

Part of the reason this is confusing is that traits often include references in their function signatures; and in particular, Clone::clone has the signature fn clone(&self) -> Self. So when T implements clone, it has a method that takes &T and returns T. But even though the signature takes &T, the type that implements Clone is T itself. (&T always implements Clone as well, just as it always implements Copy, but as with Copy, this is independent from whether T itself implements Clone. See for example the error message you get when explicitly cloning a shared reference: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a1b80cc83570321868c4ad55ee3353dc)

Since Copy is a marker trait, it doesn't have any associated methods making it explicit that Copy affects how &T can be used. However, Copy requires the type to implement Clone (even though you can implement Clone in terms of Copy) and implies that T can always be automatically created from &T without an explicit call to T::clone, so you can think of the "signature" for Copy as matching that of Clone, even though there's no actual copy method.

For #2, I recommend thinking in terms of explicit types. Adding annotations, you get:

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

The type of x is Box. You cannot assign an i32 to a Box; they're different types! But the type of *x is i32, and thus you can assign 84 to it.

The trait used to make Box behave this way is DerefMut, which explicitly makes *x assignable: https://doc.rust-lang.org/std/ops/trait.DerefMut.html