Can a Struct Extend Another Struct in Rust? Composition vs Inheritance

By the end of this page, you will understand why Rust structs do not support field inheritance like JavaScript or classical OOP languages, and what to use instead. You will learn the idiomatic Rust solution: composition—putting one struct inside another—plus how traits and wrapper types help you model shared behavior safely and clearly.

Rust does not support struct inheritance where one struct automatically gains all the fields of another struct.

If you have a type from another crate and want your own type to include it, the standard Rust solution is composition:

struct Child {
    person: Person,
    name: String,
}

This means Child contains a Person instead of being a specialized Person through inheritance.

Why Rust avoids field inheritance

Rust is designed around:

• clear ownership
• explicit data layout
• predictable behavior
• composition over inheritance

Inheritance can blur the structure of data and create tight coupling. Rust prefers simpler building blocks:

• structs for storing data
• impl blocks for methods
• traits for shared behavior
• composition for combining types

Important point about external types

Even if Person comes from another crate, you can still use it as a field inside your own struct. You do not need to modify Person to do that.

What you lose compared to inheritance

Think of Rust structs like real-world objects packed in boxes.

• In inheritance-based languages, a Child box might be treated as a larger Person box with extra compartments added on.
• In Rust, a Child box usually contains a separate Person box inside it.

So instead of saying:

• “Child is a Person with more fields”

Rust often says:

• “Child has a Person and also has more fields”

This is called composition.

A simple analogy:

• Inheritance: building a taller version of the same cabinet
• Composition: placing one cabinet inside a larger storage unit with extra drawers

Rust strongly prefers the second approach because it is explicit and easier to reason about.

The core Rust pattern is to store the existing struct as a field.

struct Person {
    gender: String,
    age: u32,
}

struct Child {
    person: Person,
    name: String,
}

You create values like this:

fn main() {
    let person = Person {
        gender: String::from("female"),
        age: 8,
    };

    let child = Child {
        person,
        name: String::from("Mia"),
    };

    println!("{} is {} years old", child.name, child.person.age);
}

If the original struct comes from another crate

That is still fine. You can do this:

use external_crate::Person;

struct Child {
    person: Person,
    name: String,
}

Adding convenience methods

If you want Child to expose part of , add methods:

Consider this example:

struct Person {
    gender: String,
    age: u32,
}

struct Child {
    person: Person,
    name: String,
}

fn main() {
    let p = Person {
        gender: String::from("female"),
        age: 7,
    };

    let c = Child {
        person: p,
        name: String::from("Ava"),
    };

    println!("{} is {} years old", c.name, c.person.age);
}

Step by step

1. Person is defined with two fields:

   • gender
   • age

2. Child is defined with:

   • person, which stores a full Person

Composition is used constantly in real Rust programs.

API request context

You may wrap a library type with your app-specific metadata:

struct AuthenticatedRequest {
    request: HttpRequest,
    user_id: String,
}

Database models

You might store a shared record and add view-specific fields:

struct UserProfile {
    user: User,
    is_online: bool,
}

Configuration objects

A crate may provide a base config type, and your app adds environment-specific settings:

struct AppConfig {
    base: ExternalConfig,
    debug_mode: bool,
}

Parsing and validation

A parsed object from a library can be wrapped with validation results:

struct CheckedDocument {
    document: ExternalDocument,
    is_valid: bool,
}

UI or game state

A reusable type can be embedded inside a richer application struct:

  {
    person: Person,
    score: ,
}

In real Rust projects, developers usually combine composition with a few common patterns.

1. Wrapper structs

A type from another crate is placed inside your own type.

struct Child {
    person: Person,
    name: String,
}

This is the most common solution.

2. Convenience methods

To avoid repeated nested access, developers add methods:

impl Child {
    fn age(&self) -> u32 {
        self.person.age
    }
}

This creates a cleaner public API.

3. Validation at construction time

A constructor can check inputs before creating the struct:

impl Child {
    fn new(person: Person, name: String) -> Self {
        Self { person, name }
    }
}

If validation is needed:

  {
     (person: Person, name: )  <, > {
         name.().() {
             (::());
        }

        ( { person, name })
    }
}

Mistake 1: Expecting field inheritance

Beginners often try to access inner fields directly as if they were inherited.

struct Child {
    person: Person,
    name: String,
}

// wrong idea
// let age = child.age;

Use:

let age = child.person.age;

Or add a method:

impl Child {
    fn age(&self) -> u32 {
        self.person.age
    }
}

Mistake 2: Thinking traits copy fields

Traits define behavior, not stored data.

trait HasAge {
    fn age(&self) -> u32;
}

A trait cannot automatically add an age field to a struct.

Mistake 3: Assuming you must modify the external crate

Composition vs inheritance

// Composition: preferred Rust approach
struct Child {
    person: Person,
    name: String,
}

Rules to remember

• Rust structs do not support field inheritance.
• Use composition to include one struct inside another.
• Use traits to share behavior, not fields.
• External crate types can still be used as fields in your own structs.
• Nested access looks like child.person.age.
• Add methods if you want a simpler API.

Common patterns

impl Child {
    fn new(person: Person, name: String) -> Self {
        Self { person, name }
    }

    fn age(&self) -> u32 {
        self.person.age
    }
}

If you only need behavior

trait HasAge {
    fn age(&self) -> ;
}

Can one struct inherit fields from another in Rust?

No. Rust does not support struct field inheritance. Use composition instead.

What is the Rust equivalent of extends for structs?

Usually there is no direct equivalent. The idiomatic replacement is to store one struct inside another.

Can I extend a struct from an external crate?

You cannot add fields to the original struct, but you can wrap it inside your own struct and add your own fields there.

Should I use traits instead of inheritance in Rust?

Use traits when you want shared behavior. Use composition when you want to store shared data.

Why does Rust prefer composition over inheritance?

Composition is explicit, flexible, and works well with Rust's ownership and safety model.

Can I make nested fields easier to access?

Yes. Add methods on your outer struct that return or expose the inner data.

Is duplicating all fields from the original struct a good idea?

Usually no. It creates maintenance problems and can drift from the original type definition.

What if I want my type to behave like the inner type?

Wrap the inner type and implement methods or traits that delegate to it.

• Structs — Rust's primary way to group related data.
• Traits — used to define shared behavior across different types.
• Ownership — important when moving an inner struct into an outer struct.
• Method implementations — useful for exposing inner data through clean APIs.
• Newtype pattern — wrapping an existing type in your own type for added meaning or behavior.
• Composition over inheritance — the core design idea behind this Rust pattern.
• Pattern matching — often used when working with nested structs and enums.
• Modules and visibility — relevant when inner fields are public or private.