TL;DR — Linear types guarantee that a value is used exactly once, turning ownership tracking into a compile‑time guarantee. This eliminates whole classes of memory‑related bugs—such as double frees and use‑after‑free—while preserving zero‑cost abstractions in languages like Rust and experimental extensions to C++.

Memory safety has long been a battleground between low‑level performance and high‑level safety guarantees. Traditional garbage‑collected languages achieve safety at the cost of runtime overhead and nondeterministic latency, while manual memory management leaves room for subtle bugs. Linear types, rooted in linear logic, offer a middle ground: they let the compiler enforce single‑use semantics without any runtime cost. In this article we unpack the theory behind linear types, examine how they are expressed in modern languages, and walk through concrete code examples that illustrate their power in building memory‑safe systems.

From Linear Logic to Linear Types

The logical foundation

Linear logic, introduced by Jean‑Yves Girard in 1987, differs from classical logic by treating propositions as resources that must be used exactly once. The core connective ⊗ (tensor) models parallel composition of resources, while ⅋ (par) represents a choice of consumption. The rule no weakening, no contraction forces each hypothesis to be consumed precisely once.

Translating this into type theory, a linear type is a type whose values cannot be duplicated or discarded implicitly. If a function takes a linear argument, the caller must either move the value to the callee or explicitly destroy it; the compiler checks these constraints statically.

Why “linear” matters for memory

In a typical heap‑allocated program, a pointer is a shareable reference: you can copy it, store it in multiple places, and later free the underlying memory. If any copy outlives the free, you get a use‑after‑free bug. Linear types prevent this by ensuring there is only one live reference to a given allocation at any point in the program.

Note – The same principle underlies Rust’s ownership model, which is formally a affine type system (allowing discarding but not duplication). Full linearity forbids discarding as well, which can be useful for tracking resources that must be explicitly released (e.g., file handles, GPU buffers) — see the linear Rust prototype in the Rust RFC 2585.

Implementing Linear Types in Practice

Rust’s ownership and borrowing as an affine approximation

Rust’s type system enforces move semantics: a value of type T is moved when assigned or passed by value, leaving the source unusable. The compiler tracks borrows (&T for shared, &mut T for exclusive) to allow temporary, read‑only or mutable access without transferring ownership.

fn consume_string(s: String) {
    println!("Consumed: {}", s);
} // `s` is dropped here

fn main() {
    let owned = String::from("hello");
    consume_string(owned); // move occurs
    // println!("{}", owned); // compile error: value moved
}

While Rust does not enforce strict linearity—values may be dropped without use (the affine property)—the model already eliminates double frees and most use‑after‑free scenarios.

Full linearity via the #[linear] attribute (experimental)

A community prototype extends Rust with a #[linear] attribute that marks a type as strictly linear. The compiler then rejects any implicit drop, forcing the programmer to call an explicit dispose method.

#[linear]
struct LinearBuffer {
    ptr: *mut u8,
    len: usize,
}

impl LinearBuffer {
    fn new(len: usize) -> Self {
        unsafe {
            let ptr = libc::malloc(len) as *mut u8;
            LinearBuffer { ptr, len }
        }
    }

    fn dispose(self) {
        unsafe { libc::free(self.ptr as *mut libc::c_void) };
    }
}

// Usage
fn use_buffer(buf: LinearBuffer) {
    // safe to read/write `buf.ptr` here
    // cannot forget to call `dispose`
}

fn main() {
    let buf = LinearBuffer::new(1024);
    use_buffer(buf); // move occurs
    // buf.dispose(); // error: `buf` moved
}

If the programmer forgets to call dispose, the compiler emits an error because the linear value would be dropped implicitly. This pattern mirrors RAII in C++ but with a compile‑time guarantee that the destructor cannot be omitted.

Linear Types in Other Languages

LanguageLinear Type SupportNotable SyntaxReference
Haskell (via LinearTypes extension)Yes (affine)a %1 -> bGHC Linear Types
CleanYes (full linear)* for uniquenessClean Language Manual
Idris 2Yes (via %linear)%linear keywordIdris 2 Docs
C++ (with std::unique_ptr)Affine approximationstd::unique_ptr<T>cppreference unique_ptr

These examples show that the core idea—single ownership enforced by the type system—is language‑agnostic, even though the exact syntax and level of strictness differ.

The Core Mechanics: Move, Borrow, and Drop

Move semantics as the engine of linearity

When a value is moved, the compiler transfers its ownership bits from the source to the destination and marks the source as uninitialized. This is the fundamental operation that guarantees a linear value cannot be accessed twice.

In Rust’s MIR (Mid-level IR), a move is represented by a Move statement that invalidates the source operand. The borrow checker then ensures no live references overlap with the move.

Borrowing without breaking linearity

Linear types often need temporary read‑only or mutable access without relinquishing ownership. Borrowing introduces lifetime constraints that guarantee the borrow ends before the original value is moved again.

fn read_len(buf: &LinearBuffer) -> usize {
    unsafe { libc::strlen(buf.ptr as *const i8) }
}

// In `main`:
let buf = LinearBuffer::new(256);
let len = read_len(&buf); // immutable borrow
buf.dispose(); // allowed after borrow ends

The borrow checker ensures that buf is not moved while &buf is alive. This mirrors the linear logic rule that a resource can be used (borrowed) but not duplicated.

Explicit disposal vs. automatic drop

In traditional affine systems (Rust, C++), the Drop trait or destructor runs automatically when a value goes out of scope. Linear systems can require explicit disposal to prevent accidental omission. The trade‑off is between ergonomics and strict guarantees.

Example: Linear I/O handle in a hypothetical language

type LinearFile = linear {
    fd: int
}

fn open(path: &str) -> LinearFile { … }
fn close(file: LinearFile) { … }

let f = open("/tmp/data");
write(f, "hello"); // borrow `f` mutably
close(f); // must be called explicitly

If close is omitted, the compiler flags an error because f would be dropped implicitly, violating linearity.

Real‑World Benefits

Eliminating double free and use‑after‑free bugs

Consider a classic C snippet:

char *buf = malloc(128);
free(buf);
free(buf); // double free!

A linear type system would assign buf a unique type UniquePtr<char>. After the first free, the value becomes invalid; any subsequent use triggers a compile‑time error.

Zero‑cost abstractions for high‑performance code

Because the checks happen at compile time, there is no runtime overhead. The generated machine code for moving a LinearBuffer is identical to a simple pointer copy, and the dispose call compiles to a single free instruction.

Benchmarks from the Linear Rust prototype show less than 1 % overhead compared to raw malloc/free patterns, while providing safety guarantees that a pure C implementation lacks.

Safer concurrency primitives

Linear ownership naturally extends to thread‑local resources. A value that is linear cannot be sent to another thread unless it is explicitly transferred, preventing data races.

use std::thread;

let buf = LinearBuffer::new(4096);
// `buf` cannot be accessed concurrently
thread::spawn(move || {
    // ownership transferred to the new thread
    process(buf);
});

The compiler enforces that the original thread no longer holds a reference, eliminating classic race conditions.

Integrating Linear Types into Existing Codebases

Gradual adoption strategy

  1. Identify resource‑heavy modules – e.g., file I/O, networking buffers, GPU resources.
  2. Introduce wrapper types – define Linear<T> structs that encapsulate raw pointers.
  3. Replace manual free/close calls with explicit dispose methods.
  4. Leverage the borrow checker to refactor functions that only need temporary access.
  5. Run the test suite – the compiler will surface any missed disposals or illegal copies.

Interoperability with non‑linear code

Linear types can be downgraded to regular references when necessary, using a safe conversion that clones the underlying data (paying the cost of a copy). This mirrors the Cow (Copy‑on‑Write) pattern in Rust.

fn into_owned(buf: LinearBuffer) -> Vec<u8> {
    // safely convert linear buffer into owned Vec
    unsafe { Vec::from_raw_parts(buf.ptr, buf.len, buf.len) }
}

The conversion consumes the linear value, preserving the guarantee that no other alias exists.

Common Pitfalls and How to Avoid Them

PitfallSymptomRemedy
Forgetting to call disposeCompiler error: “value dropped implicitly” (in strict linear mode)Ensure every linear value is moved into a function that calls dispose or use Drop with explicit #[must_use] attribute
Borrowing across move boundariesLifetime errors: “borrowed value does not live long enough”Shorten the borrow’s scope or restructure code to move after the borrow ends
Mixing linear and affine types improperlyUnexpected clone attempts, “cannot move out of Rc<T>”Keep linear resources isolated; wrap them in Box<T> only when you intend to share via reference counting
Over‑constraining APIsAPI becomes cumbersome to use for callersProvide both linear and non‑linear variants, e.g., fn write(&mut self, ...) and fn into_writer(self) -> Writer

Future Directions

Linear types for GPU and heterogeneous computing

GPU buffers often require explicit deallocation on the device. A linear type system could enforce that a buffer is submitted to the GPU exactly once and then reclaimed, preventing leaks that are hard to detect at runtime.

Integration with effect systems

Combining linearity with algebraic effects (e.g., region‑based memory management) could enable fine‑grained control over resource lifetimes without sacrificing composability.

Formal verification and model checking

Linear type systems align closely with session types used to verify communication protocols. Extending linearity to network sockets can give compile‑time guarantees that a protocol is followed correctly, as explored in the Rust async ecosystem and the Scribble project.

Key Takeaways

  • Linear types enforce single‑use semantics, turning ownership tracking into a compile‑time guarantee that eliminates double free and use‑after‑free bugs.
  • Move, borrow, and explicit disposal are the three core operations that make linearity practical in systems languages.
  • Rust’s ownership model is an affine approximation; experimental extensions (#[linear]) demonstrate how full linearity can be added without runtime cost.
  • Real‑world benefits include safer concurrency, zero‑cost abstractions, and easier reasoning about resource lifetimes across threads and devices.
  • Adopting linear types can be incremental: start with wrapper types for critical resources, replace manual deallocation with explicit dispose, and rely on the compiler to surface violations.
  • Future research points toward GPU resource management, effect‑system integration, and formal verification, expanding the reach of linear types beyond memory safety.

Further Reading