[API Proposal]: IReadOnlyMemoryOwner<T> to indicate buffer ownership and provide read-only access

[scharnyw]

Background and motivation

Both Span<T> and Memory<T> have read-only counterparts (ReadOnlySpan<T> and ReadOnlyMemory<T>) to provide read-only access but IMemoryOwner<T> currently does not.

When using IMemoryOwner<T> it is quite often that we need to transfer ownership (i.e. responsibility to dispose) and read access, but we do not intend to give the recipient write capabilities. For example, buffer could be transferred from a data producing class to a data consuming class, the latter is expected to be only reading the data and disposing of it at the end of its consumption. In such cases an IReadOnlyMemoryOwner<T> interface which provides access to a ReadOnlyMemory<T> will better document the purpose and prevent misuse.

API Proposal

namespace System.Buffers;

public interface IReadOnlyMemoryOwner<T> : IDisposable
{
    ReadOnlyMemory<T> Memory { get; }
}

public interface IMemoryOwner<T> : IReadOnlyMemoryOwner<T>
{
    new Memory<T> Memory { get; }

    // default interface implementation
    ReadOnlyMemory<T> IReadOnlyMemoryOwner<T>.Memory => Memory;
}

API Usage

var buffer = MemoryPool<T>.Shared.Rent();

// populate buffer with data

new DataConsumer().ConsumeData(buffer);

public class DataConsumer
{
    // data consumer should accept `IReadOnlyMemoryOwner<T>` to accept ownership and read-only access to the data
    public void ConsumeData(IReadOnlyMemoryOwner<T> buffer)
    {
        // work with buffer.Memory
    }
}

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[colejohnson66]

Why not just take a ReadOnlyMemory?

var buffer = MemoryPool<T>.Shared.Rent();

// populate buffer with data

new DataConsumer().ConsumeData(buffer.Memory);

public class DataConsumer
{
    public void ConsumeData(ReadOnlyMemory<T> buffer)
    {
        // work with buffer
    }
}

[scharnyw]

Why not just take a ReadOnlyMemory?

ReadOnlyMemory does not own the underlying storage. For example if DataConsumer needs to store the buffer for further processing, it would not be able to dispose of the storage (e.g. return memory to memory pool, free underlying unmanaged memory, or whatever) at the end of usage if it takes a ReadOnlyMemory.

[teo-tsirpanis]

transfer ownership (i.e. responsibility to dispose) and read access, but we do not intend to give the recipient write capabilities

This restriction does not sound right; the "owner" of a resource should be able to do anything with it. Scenarios where a memory owner is actually unable to write to it revolve around unmanaged memory, for which UnmanagedMemoryAccessor provides a better abstraction, and you can create a ReadOnlyMemory<T> around it if you want.

[scharnyw]

transfer ownership (i.e. responsibility to dispose) and read access, but we do not intend to give the recipient write capabilities

This restriction does not sound right; the "owner" of a resource should be able to do anything with it. Scenarios where a memory owner is actually unable to write to it revolve around unmanaged memory, for which UnmanagedMemoryAccessor provides a better abstraction, and you can create a ReadOnlyMemory<T> around it if you want.

I'm using the terms "own" and "ownership" because these are the wordings used in the official usage guidelines. But my understanding is that "owning" a Memory/ROM simply means that you are responsible for its lifetime management, i.e. disposing of the underlying storage at an appropriate time. It does not necessarily mean that you should have or need unrestricted access. I personally think that wording like "responsibility to dispose" would be more accurate than "ownership". Please feel free to disagree.