87

Despite thoroughly reading the documentation, I'm rather confused about the meaning of the & and * symbol in Rust, and more generally about what is a Rust reference exactly.

In this example, it seems to be similar to a C++ reference (that is, an address that is automatically dereferenced when used):

fn main() {
    let c: i32 = 5;
    let rc = &c;
    let next = rc + 1;
    println!("{}", next); // 6
}

However, the following code works exactly the same:

fn main() {
    let c: i32 = 5;
    let rc = &c;
    let next = *rc + 1;
    println!("{}", next); // 6
}

Using * to dereference a reference wouldn't be correct in C++. So I'd like to understand why this is correct in Rust.

My understanding so far, is that, inserting * in front of a Rust reference dereferences it, but the * is implicitly inserted anyway so you don't need to add it (while in C++, it's implicitly inserted and if you insert it you get a compilation error).

However, something like this doesn't compile:

fn main() {
    let mut c: i32 = 5;
    let mut next: i32 = 0;
    {
        let rc = &mut c;
        next = rc + 1;
    }
    println!("{}", next);
}
error[E0369]: binary operation `+` cannot be applied to type `&mut i32`
 --> src/main.rs:6:16
  |
6 |         next = rc + 1;
  |                ^^^^^^
  |
  = note: this is a reference to a type that `+` can be applied to; you need to dereference this variable once for this operation to work
  = note: an implementation of `std::ops::Add` might be missing for `&mut i32`

But this works:

fn main() {
    let mut c: i32 = 5;
    let mut next: i32 = 0;
    {
        let rc = &mut c;
        next = *rc + 1;
    }
    println!("{}", next);  // 6
}

It seems that implicit dereferencing (a la C++) is correct for immutable references, but not for mutable references. Why is this?

kmdreko
  • 42,554
  • 6
  • 57
  • 106
John Smith Optional
  • 22,259
  • 12
  • 43
  • 61

3 Answers3

62

Using * to dereference a reference wouldn't be correct in C++. So I'd like to understand why this is correct in Rust.

A reference in C++ is not the same as a reference in Rust. Rust's references are much closer (in usage, not in semantics) to C++'s pointers. With respect to memory representation, Rust's references often are just a single pointer, while C++'s references are supposed to be alternative names of the same object (and thus have no memory representation).

The difference between C++ pointers and Rust references is that Rust's references are never NULL, never uninitialized and never dangling.


The Add trait is implemented (see the bottom of the doc page) for the following pairs and all other numeric primitives:

  • &i32 + i32
  • i32 + &i32
  • &i32 + &i32

This is just a convenience thing the std-lib developers implemented. The compiler can figure out that a &mut i32 can be used wherever a &i32 can be used, but that doesn't work (yet?) for generics, so the std-lib developers would need to also implement the Add traits for the following combinations (and those for all primitives):

  • &mut i32 + i32
  • i32 + &mut i32
  • &mut i32 + &mut i32
  • &mut i32 + &i32
  • &i32 + &mut i32

As you can see that can get quite out of hand. I'm sure that will go away in the future. Until then, note that it's rather rare to end up with a &mut i32 and trying to use it in a mathematical expression.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
oli_obk
  • 28,729
  • 6
  • 82
  • 98
  • 2
    Thanks, I understand now. Actually, I had thought it could be something like that but I had dismissed the thought, thinking it would be very strange to define the sum of an integer with an integer's address like that. Maybe it should be emphasized in the doc that Rust references are to be thought of as addresses, and not to be confused with C++ references. Thanks again for the detailed explanation. – John Smith Optional Mar 31 '16 at 15:11
48

This answer is for those looking for the basics (e.g. coming from Google).

From the Rust book's References and Borrowing:

fn main() {
    let s1 = String::from("hello");

    let len = calculate_length(&s1);

    println!("The length of '{}' is {}.", s1, len);
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

These ampersands represent references, and they allow you to refer to some value without taking ownership of it [i.e. borrowing].

The opposite of referencing by using & is dereferencing, which is accomplished with the dereference operator, *.

And a basic example:

let x = 5;
let y = &x; //set y to a reference to x

assert_eq!(5, x);
assert_eq!(5, *y); // dereference y

If we tried to write assert_eq!(5, y); instead, we would get a compilation error can't compare `{integer}` with `&{integer}`.

(You can read more in the Smart Pointers chapter.)

And from Method Syntax:

Rust has a feature called automatic referencing and dereferencing. Calling methods is one of the few places in Rust that has this behavior.

Here’s how it works: when you call a method with object.something(), Rust automatically adds in &, &mut, or * so object matches the signature of the method. In other words, the following are the same:

p1.distance(&p2);
(&p1).distance(&p2);
mb21
  • 34,845
  • 8
  • 116
  • 142
  • I actually came here from Google specifically to get clarification on the passage you quote from "Method Syntax". My initial reading led me to believe that equating `p1.distance(&p2)` with `(&p1).distance(&p2)` must have been a typo, and that the second invocation of `distance` should have been `(*p1).distance(&p2)`. After thinking a little more about it, I've concluded there is no typo. Rust is matching the type of `p1.` with the first argument of `distance`. Is that the appropriate reading of the book? – HandsomeGorilla Jul 25 '22 at 13:51
  • 1
    yes, there is no typo. if you mean `self` with "the first argument of `distance`", then yes. – mb21 Jul 25 '22 at 14:09
  • That is precisely what I meant, thank you. – HandsomeGorilla Jul 25 '22 at 18:24
4

From the docs for std::ops::Add:

impl<'a, 'b> Add<&'a i32> for &'b i32
impl<'a> Add<&'a i32> for i32
impl<'a> Add<i32> for &'a i32
impl Add<i32> for i32

It seems the binary + operator for numbers is implemented for combinations of shared (but not mutable) references of the operands and owned versions of the operands. It has nothing to do with automatic dereferencing.

Jascha
  • 106
  • 3