Everything you loved about Span<T> — except the one restriction that makes it useless the moment you need to store it or await past it.

Try this and the compiler will stop you cold:

public class BufferHolder
{
    private Span<byte> _buffer; //  compile error: cannot use ref struct 'Span<byte>' as a field
}

public async Task ProcessAsync(Span<byte> data)
{
    await Task.Delay(100);
    Use(data); //  compile error: cannot use 'data' after 'await'
}

These aren't quirky edge-case restrictions — they're the direct, unavoidable consequence of what makes Span<T> safe in the first place, as the last two lessons flagged and deferred. A ref struct can only live on the stack, tied to one synchronous method call. A class field lives on the heap for as long as the object does. An async method's local state gets moved into a heap-allocated state machine the moment it needs to survive an await. None of those destinations can give the compiler the guarantee a Span<T> needs — so the compiler simply refuses.

In this lesson, you'll meet Memory<T> and ReadOnlyMemory<T> — the heap-friendly counterparts to Span<T>/ReadOnlySpan<T>, designed specifically to be stored, passed into async methods, and held across await, then converted back into a fast Span<T> only at the moment you're ready to do real work with it.

What Is It?

The Simple Explanation

Memory<T> represents the same idea as Span<T> — a view onto a contiguous region of memory, without owning or copying it — but packaged as an ordinary struct instead of a ref struct. That one difference in how it's declared changes everything about where it's allowed to live.

The Technical Definition

Memory<T> (in System) is an ordinary, heap-friendly struct that also represents a contiguous region of memory — typically backed by an array, though it can wrap other memory sources too. Unlike Span<T>, it is not a ref struct: it's a completely normal value type, which means it can be:

• Stored as a field of a class
• Captured by a lambda or closure
• Held across an await, as part of an async method's state machine
• Boxed, stored in a collection, passed around exactly like any other struct

What it gives up in exchange is direct, fast indexing — you don't index into a Memory<T> the way you index into a Span<T>. Instead, when you're ready to actually read or write the data, you call its .Span property, which hands you back a genuine, fast Span<T> — at which point all of Span<T>'s usual restrictions apply again, for exactly as long as you're using it. ReadOnlyMemory<T> is its read-only counterpart, following precisely the same relationship ReadOnlySpan<T> has to Span<T> from the previous lesson.

Why Does It Exist?

The Problem — the exact thing Span<T> genuinely cannot do

Span<T>'s safety comes entirely from being a ref struct, restricted to the stack, with a lifetime tied to one uninterrupted method call. That's precisely what makes it unsuitable the moment you need memory-view-like behavior to outlive a single synchronous stretch of code — which is an extremely common requirement in real applications: an object that needs to remember a buffer for later use, a lambda that needs to capture a slice, and above all, any asynchronous operation, since await can suspend and resume execution in ways that break the "one continuous stack frame" assumption Span<T> depends on.

The Solution

Memory<T> deliberately gives up the "lives only on the stack" guarantee to gain the opposite one: it can live wherever an ordinary struct can live, including the heap, for as long as needed. It still represents "a view onto memory, no copying" — it just doesn't hand you fast, direct indexing on its own. Instead, you carry a Memory<T> around through the parts of your code that need to store it or cross an await, and only convert it to a Span<T> — via .Span — at the precise, synchronous moment you're ready to actually read or write bytes quickly. That conversion is cheap and the resulting Span<T> is just as fast as one created any other way; it's simply scoped narrowly, to only the safe, synchronous window where a ref struct is allowed to exist.

Big Picture

Think of it as two tools for two different jobs on the same underlying idea: Memory<T> is what you hold onto while you're not actively working with the data; Span<T> is what you switch to for the brief, synchronous moment you actually are.

How It Works

byte[] buffer = new byte[4096];
Memory<byte> memory = buffer.AsMemory(); // no copy — same idea as AsSpan()

public class PendingWrite
{
    public Memory<byte> Data { get; } // perfectly legal — Memory<T> is not a ref struct
    public PendingWrite(Memory<byte> data) => Data = data;
}

void WriteHeader(Memory<byte> memory)
{
    Span<byte> span = memory.Span; // fast, direct access — scoped to this synchronous method
    span[0] = 0xFF;
    span[1] = 0x01;
}

Simple Example

public async Task<int> SumAfterDelayAsync(Memory<int> numbers)
{
    await Task.Delay(50); // suspension point — a Span<int> parameter would not compile here

    // Now that we're past the await, convert to a Span<int> for the actual work
    Span<int> span = numbers.Span;
    int sum = 0;
    foreach (int n in span)
        sum += n;

    return sum;
}

int[] values = [1, 2, 3, 4, 5];
int total = await SumAfterDelayAsync(values.AsMemory());
Console.WriteLine(total); // 15

What's happening: numbers is a Memory<int> parameter, so it survives the await Task.Delay(50) without any trouble — the method's compiler-generated state machine simply stores it as a field, exactly like any other ordinary struct or reference held across a suspension. Only after resuming does the method convert it to a Span<int> via .Span, and only for the brief, fully synchronous loop that follows.

Real-World Example — this is exactly why Stream.ReadAsync looks the way it does

You've called this method throughout Advanced Part IV without necessarily connecting it to this lesson: Stream.ReadAsync accepts a Memory<byte>, not a Span<byte>:

public abstract class Stream
{
    // Note the parameter type — Memory<byte>, not Span<byte>
    public virtual ValueTask<int> ReadAsync(Memory<byte> buffer, CancellationToken cancellationToken = default);
}

async Task ReadFileAsync(Stream fileStream)
{
    byte[] buffer = new byte[4096];
    int bytesRead = await fileStream.ReadAsync(buffer.AsMemory());

    Span<byte> validData = buffer.AsSpan(0, bytesRead); // now do fast, synchronous work
    Process(validData);
}

Now the design makes complete sense: ReadAsync is, by definition, an operation that suspends and resumes — that's the entire point of it being async. If ReadAsync had accepted a Span<byte> instead, the method could never actually be asynchronous in any useful way, because a Span<byte> parameter cannot legally survive the suspension an await inside the method would require. Memory<byte> is the only choice that lets an I/O API be genuinely asynchronous while still describing "here's a buffer to fill" in span-like, zero-copy terms.

Analogy

Under the Hood

Common Confusion

1. "Memory<T> is just a slower version of Span<T>"

They're not competing for the same job. Span<T> is for the moment you're actually reading or writing data, synchronously. Memory<T> is for the moment you're not — storing, passing across an await, capturing. You typically use both together in the same piece of code: Memory<T> to carry the reference, Span<T> to do the work.

2. "I should just use Memory<T> everywhere and skip Span<T> entirely"

You'd lose exactly the benefit that made this whole module worth learning: Memory<T> doesn't support fast, direct indexing the way Span<T> does — every access effectively has to go through .Span first. For a hot synchronous loop, working directly with a Span<T> the whole time is both simpler and faster; reach for Memory<T> specifically at the boundary where storage or async is genuinely required.

3. "Getting .Span from a Memory<T> copies the data"

No — exactly like slicing a Span<T>, converting a Memory<T> to a Span<T> via .Span never copies anything. It's a cheap construction of a new view over the exact same underlying memory the Memory<T> was already referencing.

Common Mistakes

Mistake 1 — Trying to make a method parameter Span<T> when it needs to be async

Writing async Task ProcessAsync(Span<byte> data) and being confused when it won't compile the moment the method body contains an await.

If a method is genuinely async and needs the buffer both before and after an await, its parameter has to be Memory<byte> (or ReadOnlyMemory<byte>) — convert to .Span only in the fully synchronous portions.

Mistake 2 — Holding onto a .Span result across an await inside the same method

async Task BadAsync(Memory<byte> memory)
{
    Span<byte> span = memory.Span;
    await Task.Delay(10); //  compile error: 'span' is used after this await
    span[0] = 1;
}

Don't call .Span until after every await that comes before the work you need it for — the compiler will catch this anyway, but understanding why makes the error obvious on sight instead of confusing.

Mistake 3 — Reaching for Memory<T> when a method is entirely synchronous

Using Memory<T> parameters throughout a codebase "for consistency," even in purely synchronous helper methods that never store or capture the data.

Default to Span<T>/ReadOnlySpan<T> for ordinary synchronous methods — they're simpler, and every caller with a Memory<T> can trivially pass .Span to one anyway. Reach for Memory<T> specifically at genuine storage or async boundaries.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've seen why Memory<T> exists and how it partners with Span<T>. Let's confirm the distinction is solid.

You now know exactly when to reach for Memory<T> versus Span<T> — and why async I/O in .NET is shaped the way it is. Next: how to avoid allocating the buffers themselves in the first place, with ArrayPool<T>.

dotnetmadeeasy.com — Learn C# and .NET, the right way.