Why shouldn't we use & in HashSet::insert?

I am learning Rust after C++. Want to understand why shouldn't we use & in HashSet::insert() function?

We are using & in HashSet::contains() function because we don't want to own object
I would expect the same for the insert()

I was reading documentation https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.insert and understand signature of the method pub fn insert(&mut self, value: T) -> bool
Why don't we use &value ?

My code

use std::collections::HashSet;


fn main() {
    let mut hset = HashSet::new();
    let num = 111;

    hset.insert(num);
    if hset.contains(&num) {
        println!("Contains {}", num);
    }

    println!("{:?}", hset);
} 

Let me try to use a metaphor: your HashSetis a bag, and your T is the type of things you can put into that bag. You own the bag and are responsible to run my requests.

So now when I use HashSet::contains() I am holding an object, for example a red ball, and I ask you: Is there a similar object in the bag? Note that the ball is mine, but I let you borrow it so you can use it to compare to the objects inside the bag. When you are done you return the borrowed object and reply with "yes" or "no".

But when I use HashSet::insert() I give you the ball, and you insert that very same ball into the bag. If a similar object is already in the bag, then you trash the new ball (you do not want duplicated objects in your bag!) and reply "no". Else you insert the ball into the bag and reply "yes". Note that in either case now I do not have the ball any more.

So in the contains() case you pass a reference with & because you are borrowing the object to be used for a while. But with insert() you pass the object itself as an owned value so that the container is able to own it.

In many cases you will want the HashSet to own the values it contains. In those cases you just want to pass the values directly, i.e. to move them, when calling insert().

However, the above doesn't mean you can't store references to objects instead. If you call hset.insert(&num), the compiler will infer the HashSet type as something like HashSet<&i32> (if num's type is ì32).

You can test that with this code:

use std::collections::HashSet;

fn main() {
    let mut hset = HashSet::new();
    let num: i32 = 111;
    hset.insert(&num);
    hset.aaaaa();
}

the compiler will tell you this:

error[E0599]: no method named `aaaaa` found for struct `HashSet` in the    current scope
 --> src/main.rs:7:10
  |
7 |     hset.aaaaa();
  |          ^^^^^ method not found in `HashSet<&i32>`

BTW in the above example I explicitly set num's type to be ì32. If we didn't specify that, the compiler's output might be a bit more generic in its message, but still specific enough: HashSet<&{integer}> (i.e., it can still infer you're trying to store a reference to some integer).

Note that for simple types like i32 there's rarely a need to store references to such values, since making a copy of the value is usually a lot more efficient. If you wanted to store strings though, it depends. For short strings cloning those is usually a simple and fast enough approach. For longer string you might want to avoid cloning by using HashSet<&str> instead, but then you might need some extra consideration/work w.r.t. ownership and lifetimes.