It may be worth pointing out that the `Option&lt;T&gt;` type in Rust doesn&#x27;t inherently involve any pointers at all, assuming `T` is not a pointer type itself.<p>For example, `Option&lt;i32&gt;` is probably (the compiler gets to choose) going to be represented as two four-byte values: the discriminant, which distinguishes the `Some` and `None` cases, and then a space for the value `v`, for when the discriminant says we have `Some(v)`. Since zero is a perfectly fine value for an `i32`, we have to store the discriminant separately.<p>But note that this is just a flat eight-byte value. There&#x27;s no heap allocation involved. It&#x27;s just as if you&#x27;d written in C:<p><pre><code>    struct O { enum { Some, None } discriminant; int32_t value };
</code></pre>
I compiled a program that uses `Option&lt;Option&lt;i32&gt;&gt;`, and looked at the DWARF debugging info to see what the compiler did with it. It seems to represent this as a twelve-byte value: four bytes for the discriminant for the outer `Option`, followed an eight-byte `Option&lt;i32&gt;` value laid out as before. Since you can get the address of a value held by an enum, I guess this makes sense; the compiler can&#x27;t combine the discriminants or do anything clever like that.