Are there differences between .to_owned(), .clone() and dereferencing (*)?

With this code on the rust playground:

fn main() {
    let a = &[1, 2, 3];
    
    let mut o = a.to_owned();
    let mut c = a.clone();
    let mut d = *a;
    
    o[0] = 7;
    c[0] = 8;
    d[0] = 9;
    
    println!("o: {:?}", o);
    println!("c: {:?}", c);
    println!("d: {:?}", d);
    println!("a: {:?}", a);
}

I see:

o: [7, 2, 3]
c: [8, 2, 3]
d: [9, 2, 3]
a: [1, 2, 3]

All three methods clone the contents of a.

Are there any differences?

For a reference to an instance of Copy there is no difference.
That is because for Copy types:

1. *ref_to_val returns a bitwise copy of val (and doesn't invalidate old value).
2. The derived Clone impl. for Copy types will implement .clone() using *.
3. The blanket ToOwned impl. for Clone types will implement .to_owned() using .clone().

So it all boils down to bitwise copy.
This is your case.

If you want to understand how traits Deref, Clone, ToOwned work for !Copy types, you have to understand their purpose and read type-specific docs.
I believe String and str types are very representative !Copy types that will help you understand the magic. Eg. str is ToOwned, but not Deref or Clone. Your example won't work for these types.

Assuming that all relevant traits are implemented sensibly, all three will have the same result, and should be equally efficient when compiled with optimization. The differences are in which ones are allowed under what conditions, and what they guarantee. Thus, if you are writing generic code (code that works with many different types) it may matter which one you pick, but if the code is not generic, it does not matter other than for readability.

• * dereference (without immediately referencing the result) will only compile if the referent of the reference you're dereferencing (the T in &T) implements the Copy trait. In that case, it is guaranteed that the result is an exact byte-for-byte copy of the original value the reference pointed to.

• .clone(), that is, Clone::clone(), will only compile if the type of the referent implements the Clone trait. In that case, it is guaranteed that the result is of the same type as the referent: it goes from &T to T. There are no compiler-enforced guarantees that the value is identical, but it is expected that Clone implementations will give you meaningfully “another copy of the same value”, even if its byte representation is different; for example, cloning a Vec will give you a Vec that has a different heap allocation pointer, but the contents will be a clone of the original vector's contents.

  All types that implement Copy must also implement Clone, and you can reasonably expect that those types will produce the same result from using either. (That is, if Clone::clone() does something different from copying, the implementation is violating documented expectations.)

• .to_owned(), that is, ToOwned::to_owned(), will only compile if the type of the referent implements the ToOwned trait. This trait is essentially the same as Clone, except that the result type is not required to be the same as the referent type; for example, calling .to_owned() on an &str will give you a String, not a str — which is good, because str cannot be returned by value without some wrapper. This is why ToOwned exists distinct from Clone — to support making clones of dynamically-sized types.

  All types that implement Clone automatically implement ToOwned via a blanket implementation. Thus, the only types that implement ToOwned in an interesting way are those which do not implement Clone; these are usually dynamically sized types.

To write good Rust code:

• If you can use a dereference, do that.
• If you cannot use a dereference, use .clone().
• If you cannot use .clone(), use .to_owned().
• If none of those work, then consult the type's documentation:
  • it may have a specialized operation (e.g. File::try_clone());
  • it may be fundamentally something you can't make a clone of, in which case you may want to share the single instance with Rc or Arc, or you may need to do something completely different; or
  • the author of the code may have forgotten to provide a Copy, Clone, or ToOwned implementation.