.NET Value Type Copying: Method Calls Explained

Hey guys! Let's dive into a quirky behavior in .NET regarding value type copying when calling methods, especially when dealing with ref readonly variables. This can be a bit confusing, so let's break it down.

The Mystery of the Copying this

So, the main issue revolves around what happens when you chain calls to non-readonly member methods from a ref readonly variable. Imagine you have a function, GetRef, that returns a ref readonly to a struct. When you call methods on this returned reference, the this pointer inside the method might point to a copy of the struct on the stack, not the original one. This is super important, especially when you're working with pointers and memory addresses directly.

Let's look at the example code provided:

unsafe static void Test()
{
    var v = new MyStruct();
    var p = (nint)(&v);

    var p1 = v.GetThisAddress();
    var p2 = ((MyStruct*)p)->GetThisAddress();
    var p3 = Unsafe.AsRef<MyStruct>((void*)p).GetThisAddress();
    var p4 = GetRef(in *(MyStruct*)p).GetThisAddress();
    var p5 = GetRef(in Unsafe.AsRef<MyStruct>((void*)p)).GetThisAddress();

    Console.WriteLine({{content}}quot;p1={p1}");
    Console.WriteLine({{content}}quot;p2={p2}");
    Console.WriteLine({{content}}quot;p3={p3}");
    Console.WriteLine({{content}}quot;p4={p4}");
    Console.WriteLine({{content}}quot;p5={p5}");
}

unsafe static ref readonly T GetRef<T>(ref readonly T value) where T : unmanaged
{
    return ref value;
}

unsafe struct MyStruct
{
    public string GetThisAddress()
    {
        fixed (void* p = &this)
        {
            return {{content}}quot;0x{(nint)p:x16}";
        }
    }
}

When you run this code, you'll notice that p4 and p5 have different memory addresses than p1, p2, and p3. This is because GetRef returns a ref readonly, and calling GetThisAddress on it results in a copy. Let's break down what's happening:

• p1, p2, and p3: These calls directly access the original struct v or its memory address. So, GetThisAddress operates on the original struct.
• p4 and p5: Here's where the magic happens (or the confusion, depending on your perspective!). GetRef returns a ref readonly. When you call GetThisAddress on this, the compiler sees a non-readonly method being called on a readonly reference. To ensure safety, it creates a copy of the struct on the stack, and this inside GetThisAddress points to this copy. This is a crucial point to understand because it means any modifications you make through this inside GetThisAddress won't affect the original struct.

Why Does This Happen?

The main reason for this behavior is to maintain const-correctness. A ref readonly promises that the referenced value won't be modified. If you could call a non-readonly method directly on a ref readonly without a copy, you'd be breaking that promise. By creating a copy, the non-readonly method can do its thing without risking changes to the original value. This is a really important concept in many programming languages, ensuring that read-only guarantees are truly upheld and preventing unexpected side effects.

Implications and Gotchas

This copying behavior can lead to unexpected results if you're not aware of it. Imagine you're working with a struct that represents a resource, like a file handle or a network connection. If you accidentally operate on a copy, you might end up with resource leaks or other issues. It's crucial to always be mindful of whether you're operating on the original value or a copy, especially when dealing with ref readonly and non-readonly methods.

The COM Interface Wrapper Scenario

The original poster brought up a very practical scenario: writing a wrapper for COM interface pointers. This is a common task when interacting with older Windows APIs, and it highlights the challenges this copying behavior can introduce.

The goal is to create a ComPtr<T> struct that encapsulates a COM interface pointer. The struct needs to handle things like reference counting (AddRef, Release), querying for interfaces (QueryInterface), and disposing of the pointer when it's no longer needed. Here's the original code snippet:

internal partial struct ComPtr<T> : IDisposable
    where T : unmanaged, Windows.Win32.IComIID
{
    private nint ptr;

    public readonly bool IsNull => ptr == 0;

    // AddRef, Release, QueryInterface, Dispose ...

    public unsafe readonly T* Get() =>
        (T*)ptr;

    // Note: Get2 correctly returns a ref readonly, but subsequent 
    // method calls on the returned reference may still cause copying when 
    // calling non-readonly methods
    public unsafe readonly ref readonly T Get2() =>
        ref Unsafe.AsRef<T>((void*)ptr);

    public unsafe readonly T** GetAddressOf() =>
        (T**)Unsafe.AsPointer(ref GetThisRef().ptr);

    public unsafe readonly void** GetAddressOfAny() =>
        (void**)Unsafe.AsPointer(ref GetThisRef().ptr);
}

The Get2 method is designed to return a ref readonly T, providing a safe way to access the underlying COM interface. However, as we've discussed, calling non-readonly methods on this reference can lead to copying, which is exactly what we want to avoid when working with COM interfaces. COM interfaces rely on identity; operating on a copy is almost always wrong.

The usage example highlights the issue:

using var comPtr = default(ComPtr<ISomeInterface>);

var hr = Windows.Win32.PInvoke.CoCreateInstance(
    in Guids.CLSID_SomeInterface,
    null,
    CLSCTX.CLSCTX_ALL,
    in ISomeInterface.IID_Guid,
    out *comPtr.GetAddressOfAny());

comPtr.Get()->XXX();

The -> operator is unsafe, and the await keyword can't be used in unsafe contexts. This makes the Get()->XXX() approach less than ideal for asynchronous operations or cleaner code.

The Core Problem: Balancing Safety and Usability

The core challenge here is balancing safety (avoiding copies) with usability (making the code easy to write and maintain). Returning a ref readonly is generally a good practice for safety, but the copying behavior can create headaches in scenarios like COM interop.

Potential Solutions and Workarounds

So, what can we do to address this? Here are a few approaches:

1. Mark Methods as readonly

The most straightforward solution is to ensure that all methods called on the ref readonly are themselves marked as readonly. This tells the compiler that the method won't modify the struct's state, and it can safely operate on the original value without creating a copy. This is the recommended approach whenever possible, promoting both safety and efficiency.

Consider, if the XXX() method from the example was marked as readonly, no copying would occur.

2. Return a ref Instead of ref readonly (Use with Caution!)

Another option is to return a ref instead of a ref readonly. This gives the caller direct access to the underlying struct, allowing them to call non-readonly methods without copying. However, this approach comes with a significant caveat: it bypasses the const-correctness guarantees of ref readonly. You're essentially saying,