A Comprehensive Guide to Rust Standard Library Traits: Memory Management and Type Conversion

Introduction

When building software systems, defining and using appropriate traits is key to making the code structure highly extensible and flexible. The Rust standard library provides a rich set of traits, and using them correctly not only clarifies the code structure but also aligns better with the conventions of the Rust ecosystem. This article will delve into the key traits in Rust, including those related to memory management, marker traits, type conversion, and operator traits.

Memory-Related Traits: Clone / Copy / Drop

Clone Trait

Clone trait is used to define the deep copy behavior of data:

pub trait Clone {
    fn clone(&self) -> Self;
    fn clone_from(&mut self, source: &Self) {
        *self = source.clone()
    }
}

Clone trait has two methods: clone() and clone_from(), the latter has a default implementation, so usually we only need to implement clone(). You might wonder about the purpose of clone_from(), as a.clone_from(&b) seems equivalent to a = b.clone().

In fact, they are not entirely the same. If a already exists and the clone operation would allocate memory, using a.clone_from(&b) can avoid allocation and improve efficiency.

If every field of a data structure implements Clone, you can simplify the code using the #[derive(Clone)] macro:

#[derive(Clone, Debug)]
struct Developer {
    name: String,
    age: u8,
    lang: Language
}

#[allow(dead_code)]
#[derive(Clone, Debug)]
enum Language {
    Rust,
    TypeScript,
    Elixir,
    Haskell
}

fn main() {
    let dev = Developer {
        name: "Tyr".to_string(),
        age: 18,
        lang: Language::Rust
    };
    let dev1 = dev.clone();
    println!("dev: {:?}, addr of dev name: {:p}", dev, dev.name.as_str());
    println!("dev1: {:?}, addr of dev1 name: {:p}", dev1, dev1.name.as_str());
}

Running this code shows that for name (a String type), the heap memory is also cloned, so Clone is a deep copy—both stack and heap contents are copied.

Copy Trait

Unlike Clone, Copy has no methods—it is a marker trait. Its definition is:

pub trait Copy: Clone {}

From the definition, it can be seen that to implement Copy, a type must first implement Clone, and then implement an empty Copy trait. You might ask: what is the use of a trait with no behavior?

Although it has no methods, it can serve as a trait constraint for type safety checks—hence it is called a marker trait.

If all fields of a data structure implement Copy, you can derive Copy using #[derive(Copy)]. If you try to add Copy to Developer and Language:

#[derive(Clone, Copy, Debug)]
struct Developer {
    name: String,
    age: u8,
    lang: Language
}

#[derive(Clone, Copy, Debug)]
enum Language {
    Rust,
    TypeScript,
    Elixir,
    Haskell
}

This code will fail: String does not implement Copy. Therefore, Developer can only be cloned, not copied. Remember: if a type implements Copy, assignment and function calls will copy the value; otherwise, ownership will be moved.

Drop Trait

We have discussed Drop in the memory management section. Here is its definition:

pub trait Drop {
    fn drop(&mut self);
}

In most cases, you do not need to manually implement Drop for your types: the system will automatically call the drop method for each field in the data structure in order. However, there are two situations where you might need to implement Drop manually:

When you want to perform certain operations at the end of the data’s lifecycle, such as logging
When you need to release external resources. The compiler does not know about any additional resources you might hold, so it cannot release them for you

Note that the Copy trait and the Drop trait are mutually exclusive; both cannot coexist. When you try to implement both Copy and Drop for the same data type, the compiler will give an error. This is easy to understand:Copy performs shallow bitwise copies, assuming that the copied data has no resources to release; while the existence of Drop is precisely to release additional resources.

Marker Traits: Sized / Send / Sync / Unpin

Sized Trait

Sized trait marks types with a specific size. When using generic parameters, Rust automatically adds a Sized constraint to the generic parameters:

struct Data<T> {
    inner: T,
}

fn process_data<T>(data: Data<T>) {
    todo!();
}

This is equivalent to:

struct Data<T: Sized> {
    inner: T,
}

fn process_data<T: Sized>(data: Data<T>) {
    todo!();
}

In most cases, we want this constraint to be added automatically, as it allows the size of the generic structure to be fixed at compile time, enabling it to be passed as a function parameter. However, this automatically added constraint is not always suitable. In rare cases, we want T to be dynamically sized. What should we do? Rust provides ?Sized to lift this constraint.

Send / Sync

Send and Sync are the foundation of Rust’s concurrency safety:

If a type T implements the Send trait, it means that T can be safely moved from one thread to another, i.e., its ownership can be transferred between threads
If a type T implements the Sync trait, it means that &T can be safely shared between multiple threads. A type T satisfies the Sync trait if and only if &T satisfies the Send trait

For user-defined data structures, if all their internal fields implement Send / Sync, then the data structure itself will automatically implement Send / Sync. Basically, native data structures support Send / Sync, so the vast majority of custom data structures also satisfy Send / Sync. In the standard library, data structures that do not support Send / Sync mainly include:

Raw pointers *const T / *mut T. They are unsafe, so neither Send nor Sync is applicable
UnsafeCell<T> does not support Sync. That is, any data structure using Cell or RefCell does not support Sync
Reference counting Rc supports neither Send nor Sync, so Rc cannot be used across threads

Type Conversion: From / Into / AsRef / AsMut

In software development, we often need to convert one data structure into another in certain contexts. Rust provides two sets of traits for conversions between value types and reference types:

Value to value conversion: From<T> / Into<T> / TryFrom<T> / TryInto<T>
Reference to reference conversion: AsRef<T> / AsMut<T>

From / Into

First, let’s look at From<T> and Into<T>. Their definitions are as follows:

pub trait From<T> {
    fn from(T) -> Self;
}

pub trait Into<T> {
    fn into(self) -> T;
}

When you implement From<T>, Into<T> is automatically implemented. This is because:

// Implementing From automatically implements Into
impl<T, U> Into<U> for T where U: From<T> {
    fn into(self) -> U {
        U::from(self)
    }
}

So in most cases, it is sufficient to implement From<T>, and both conversion methods will work. For example:

let s = String::from("Hello world!");
let s: String = "Hello world!".into();

These two methods are equivalent. Which one should you choose?From<T> can infer types based on context and has more use cases; additionally, since implementing From<T> will automatically implement Into<T> rather than the other way around, you should implement From<T> when needed, not Into<T>.

Using From<T> and Into<T> can make function interfaces more flexible. For example:

use std::net::{IpAddr, Ipv4Addr, Ipv6Addr};

fn print(v: impl Into<IpAddr>) {
    println!("{:?}", v.into());
}

fn main() {
    let v4: Ipv4Addr = "2.2.2.2".parse().unwrap();
    let v6: Ipv6Addr = "::1".parse().unwrap();
    
    // IPAddr implements From<[u8; 4]> to convert IPv4 addresses
    print([1, 1, 1, 1]);
    
    // IPAddr implements From<[u16; 8]> to convert IPv6 addresses
    print([0xfe80, 0, 0, 0, 0xaede, 0x48ff, 0xfe00, 0x1122]);
    
    // IPAddr implements From<Ipv4Addr>
    print(v4);
    
    // IPAddr implements From<Ipv6Addr>
    print(v6);
}

AsRef / AsMut

Having understood From<T> / Into<T>, understanding AsRef<T> and AsMut<T> becomes easy. They are used for conversions from reference to reference. First, let’s look at their definitions:

pub trait AsRef<T> where T: ?Sized {
    fn as_ref(&self) -> &T;
}

pub trait AsMut<T> where T: ?Sized {
    fn as_mut(&mut self) -> &mut T;
}

In the trait definitions, T can be a dynamically sized type, such as str, [u8], etc. AsMut<T> is similar to AsRef<T>, except it generates a mutable reference from a mutable reference, so we mainly focus on AsRef<T>.

Let’s look at the interface for opening files in the standard library: std::fs::File::open:

pub fn open<P: AsRef<Path>>(path: P) -> Result<File>

The parameter path is a type that satisfies AsRef<Path>, so you can pass types like String, &str, PathBuf, Path, etc. Additionally, when you use path.as_ref(), you will get a &Path.

Let’s write some code to experience the use and implementation of AsRef<T>:

#[allow(dead_code)]
enum Language {
    Rust,
    TypeScript,
    Elixir,
    Haskell,
}

impl AsRef<str> for Language {
    fn as_ref(&self) -> &str {
        match self {
            Language::Rust => "Rust",
            Language::TypeScript => "TypeScript",
            Language::Elixir => "Elixir",
            Language::Haskell => "Haskell",
        }
    }
}

fn print_ref(v: impl AsRef<str>) {
    println!("{}", v.as_ref());
}

fn main() {
    let lang = Language::Rust;
    // &str implements AsRef<str>
    print_ref("Hello world!");
    // String implements AsRef<str>
    print_ref("Hello world!".to_string());
    // Our custom enum also implements AsRef<str>
    print_ref(lang);
}

Operator-Related: Deref / DerefMut

Deref and DerefMut are operator-related traits, defined as follows:

pub trait Deref {
    // The type of the dereferenced result
    type Target: ?Sized;
    fn deref(&self) -> &Self::Target;
}

pub trait DerefMut: Deref {
    fn deref_mut(&mut self) -> &mut Self::Target;
}

As you can see, DerefMut “inherits” from Deref, but additionally provides a deref_mut method to obtain a mutable dereference.

For ordinary references, dereferencing is intuitive, as it only has one address pointing to the value, from which the desired value can be obtained, as shown in the following example:

let mut x = 42;
let y = &mut x;
// Dereferencing internally calls DerefMut (which is implemented as *self)
*y += 1;

But for smart pointers, dereferencing which field is not intuitive. Let’s see how the Rc we learned earlier implements Deref:

impl<T: ?Sized> Deref for Rc<T> {
    type Target = T;
    fn deref(&self) -> &T {
        &self.inner().value
    }
}

It can be seen that it ultimately points to the value inside the RcBox on the heap, and dereferencing yields the value corresponding to value.

In Rust, most smart pointers implement Deref, and we can also implement Deref for our own data structures. Here is an example:

use std::ops::{Deref, DerefMut};

#[derive(Debug)]
struct Buffer<T>(Vec<T>);

impl<T> Buffer<T> {
    pub fn new(v: impl Into<Vec<T>>) -> Self {
        Self(v.into())
    }
}

impl<T> Deref for Buffer<T> {
    type Target = [T];
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

impl<T> DerefMut for Buffer<T> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.0
    }
}

fn main() {
    let mut buf = Buffer::new([1, 3, 2, 4]);
    // Because we implemented Deref and DerefMut, buf can directly access the sort method
    // This line is equivalent to: (&mut buf).deref_mut().sort()
    buf.sort();
    println!("buf: {:?}