Marker Trait

A marker trait in Rust is an interface that contains no methods, associated types, or associated constants. Instead of defining executable behavior, a marker trait acts as a compile-time tag to communicate specific structural properties, memory invariants, or concurrency guarantees about a type directly to the Rust compiler.

// Definition of a standard marker trait
pub trait IsTriviallyCopyable {}

struct DataBuffer {
    buffer: [u8; 256],
}

// Implementation requires no method definitions
impl IsTriviallyCopyable for DataBuffer {}

Technical Mechanics

Zero Runtime Cost Because marker traits lack methods and associated data, they do not emit any executable machine code. They are entirely erased during the compilation phase, existing strictly for static analysis, type checking, and trait bound resolution. Note that if a marker trait is used as a trait object (e.g., &dyn IsTriviallyCopyable), the compiler will still generate a vtable containing the underlying type’s size, alignment, and drop_in_place pointer, even though no trait methods are present.

Trait Bounds Marker traits are evaluated and enforced during the type-checking phase (well before monomorphization). They are used to constrain generic type parameters, forcing the compiler to reject types that do not explicitly carry the required tag before any code generation occurs.

// The compiler enforces that T carries the IsTriviallyCopyable tag during type checking
fn process_memory<T: IsTriviallyCopyable>(data: &T) {
    // ...
}

Auto Traits (OIBITs)

A specialized subset of marker traits in Rust are Auto Traits (historically known as Opt-In Built-In Traits). Defined using the auto keyword (currently unstable for custom traits), these are automatically implemented by the compiler for any type whose constituent fields all implement the trait.

The standard library relies heavily on auto marker traits to enforce memory and concurrency safety:

• Send: Signals that a type’s ownership can be safely transferred across thread boundaries.
• Sync: Signals that a type is safe to share across threads via shared references (&T).
• Unpin: Signals that a type can be safely moved in memory after being pinned.

Note: Other fundamental marker traits like Sized and Copy are automatically implemented or derived by the compiler based on structural rules, but they are fundamental language items, not auto traits.

Opting Out of Auto Traits

Because auto marker traits are applied structurally by the compiler, a type will automatically inherit traits like Send and Sync if all its fields possess them. To explicitly remove an auto trait, developers must interrupt this structural resolution.

The Stable Approach: PhantomData The standard, stable mechanism to opt out of an auto trait is to embed a zero-sized marker type that inherently lacks the target trait. std::marker::PhantomData is used to hold a type like a raw pointer (*const ()), which the compiler knows is neither Send nor Sync.

use std::marker::PhantomData;

struct ThreadLocalCounter {
    count: u64, // u64 is inherently Send + Sync
    
    // *const () is !Send and !Sync.
    // PhantomData consumes no memory at runtime but forces the compiler 
    // to evaluate ThreadLocalCounter as !Send and !Sync during type checking.
    _marker: PhantomData<*const ()>,
}

The Unstable Approach: Negative Implementations Rust also possesses a direct syntax for removing auto traits using a negative implementation (!). This explicitly tells the compiler that the type violates the invariant represented by the marker trait. However, this feature is currently unstable for user code and requires a nightly compiler flag.

#![feature(negative_impls)]

struct ThreadLocalCounter {
    count: u64, 
}

// Explicitly removing the Send marker trait.
// Note: Negative implementations cannot be marked `unsafe`.
impl !Send for ThreadLocalCounter {}

Master Rust with Deep Grasping Methodology!

Learn More