Ownership & Borrowing

1. The Mental Model

If you come from C, the most useful first step is to stop thinking about ownership as "owning a memory address."

There are three concepts that are easy to accidentally mix together:

2. Start With What You Know: C

Let's begin with a familiar C example.

Widget *w = malloc(sizeof(Widget));

At a low level, you can imagine:

But C doesn't tell the compiler what the pointer means.

Is w the owner? Is it borrowing the object? Can another pointer free it? Is somebody else responsible?

Widget *a = malloc(sizeof(Widget)); Widget *b = a;

A human programmer might establish a convention such as:

a owns the Widget. b merely borrows it.

But the ordinary C pointer type does not encode that distinction.

free(a); free(b);

free(a);

printf(
"%d",
b->value
);

Widget *a = malloc(...);

/* forgot free */

3. What Does "Owned" Actually Mean?

Suppose we have:

String name = make_string("Alice");

The useful question is not:

Instead ask:

The owner is the value/storage location whose responsibility includes the object's lifetime and eventual destruction.

4. Is It the Memory Slot?

This is probably the most important question for someone coming from C.

It is tempting to imagine:

But that is too implementation-focused.

A better model is:

5. Moving Ownership

One of the biggest differences from C is the idea of explicitly transferring ownership.

String a = make_string("hello");

String b = move(a);

Before the move:

After the move:

Why is this useful?

Because destruction remains unambiguous.

6. Borrowing

What if we don't want to transfer ownership? We simply want another function to use the object.

String name = make_string("Alice");

String* p = &name;

Conceptually:

Compare this with C

In C, you might simply pass a pointer:

void print_widget(Widget *w) { printf("%d", w->value); }

A programmer may intend:

"print_widget borrows w."

But the C type Widget * doesn't encode that ownership relationship.

In an ownership-oriented language, the managed pointer represents an access capability whose lifetime and aliasing are subject to the language's rules.

7. Shared Borrows

A shared borrow means:

Multiple shared borrows can exist simultaneously.

The owner still exists behind the scenes:

String name = make_string("Alice");

String* p = &name;
String* q = &name;

/* p and q can both read name */

This is conceptually very different from unrestricted pointer aliasing in C.

8. Mutable Borrows

Now suppose we want to modify the object.

mut String* p = &mut name;

The important idea is:

Why exclusive?

Imagine two pointers:

9. Lifetimes

Borrowing immediately creates another question:

Suppose:

String name = make_string("Alice");

String* p = &name;

The borrow cannot remain valid after name is destroyed.

Compare this with C

Widget *get_widget(void)
{
    Widget w;
    return &w;
}

The pointer returned by this function refers to a local object whose lifetime ends when the function returns.

C allows you to form the pointer. Using it later is undefined behavior.

An ownership-aware language attempts to detect this kind of invalid lifetime relationship.

10. Destruction

Ownership becomes particularly useful when we talk about destruction.

fn example()
{
    String name = make_string("Alice");

    // use name

} // ownership ends here

The important question is:

The owner.

11. Managed Pointers vs Raw Pointers

This is especially important when coming from C.

12. The Same Problem: C vs Ownership

C version

Widget *create_widget(void)
{
    Widget *w = malloc(sizeof(Widget));

    if (!w)
        return NULL;

    w->value = 42;

    return w;
}

void use_widget(Widget *w)
{
    printf("%d\n", w->value);
}

int main(void)
{
    Widget *w = create_widget();

    use_widget(w);

    free(w);

}

A human reader may infer:

But those relationships are mostly in the programmer's head.

Ownership-oriented version

Widget w = create_widget();

use_widget(&w);

/* w remains owned here */

/* scope ends - w is destroyed */

13. The Three Most Important Relationships

14. Common Mental Mistakes

15. A Simple Set of Rules

You do not need to memorize the entire specification yet. Start with these rules.

16. The Big Picture

Put everything together and ownership languages are really answering four questions.

17. Translate Ownership Concepts Into C Terms

When reading an ownership-oriented specification, this translation can help.

18. Test Your Mental Model

19. One-Page Cheat Sheet

20. Where to Go Next

Once this mental model feels comfortable, the natural progression is: