[API Proposal]: Add CollectionsMarshal.AsMemory(List<T>)

[Neme12]

Background and motivation

The existing CollectionsMarshal.AsSpan method is really useful in order to be able to get a span from a List<T>, however, in many scenarios, e.g. when calling async methods, what you really need is a Memory<T> instead. Since you can't get a Memory<T> from a Span<T>, you currently need to make a copy of the data. This could be avoided if there was an ability to get a Memory<T> directly from a List<T>.

API Proposal

 namespace System.Runtime.InteropServices;

 public static class CollectionsMarshal
 {
     // Existing method:
     public static Span<T> AsSpan<T>(List<T>? list)

     // New method:
+    public static Memory<T> AsMemory<T>(List<T>? list)
 }

and if #90138 is approved, then also:

 namespace System.Runtime.InteropServices;

 public static class ImmutableCollectionsMarshal
 {
     // Method proposed in #90138:
     public static Span<T> AsSpan<T>(ImmutableArray<T>.Builder? builder);

     // New method:
+    public static Span<T> AsMemory<T>(ImmutableArray<T>.Builder? builder);
 }

API Usage

async Task FooAsync(TextWriter writer)
{
    var list = new List<char>();
    // ...fill the collection
    await writer.WriteAsync(CollectionsMarshal.AsMemory(list));
}

Alternative Designs

No response

Risks

No response

[ghost]

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

Issue Details

---

Background and motivation

The existing CollectionsMarshal.AsSpan method is really useful in order to be able to get a span from a List<T>, however, in many scenarios, e.g. when calling async methods, what you really need is a Memory<T> instead. Since you can't get a Memory<T> from a Span<T>, you currently need to make a copy of the data. This could be avoided if there was an ability to get a Memory<T> directly from a List<T>.

API Proposal

 namespace System.Runtime.InteropServices;

 public static class CollectionsMarshal
 {
     // Existing method:
     public static Span<T> AsSpan<T>(List<T>? list)

     // New method:
+    public static Memory<T> AsMemory<T>(List<T>? list)
 }

API Usage

async Task FooAsync(TextWriter writer)
{
    var list = new List<char>();
    // ...fill the collection
    await writer.WriteAsync(CollectionsMarshal.AsMemory(list));
}

Alternative Designs

No response

Risks

No response

Author:	Neme12
Assignees:	-
Labels:	api-suggestion, area-System.Memory
Milestone:	-

[Tornhoof]

The AsMemory method was specifically excluded in the original API Review, see #27061 (comment) (and specifically the video).

[huoyaoyuan]

See also #87210.

[Neme12]

Could this not be revisited? It's been 4 years since that API review.

[stephentoub]

While AsSpan(List<T>) baked in the notion of List<T> being backed by contiguous memory, AsMemory(List<T>) would effectively bake in the notion of it being backed by a T[]. That's something we'd like to avoid doing right now. (Such an AsMemory could return a Memory backed by a MemoryManager, but that would then either require that AsMemory to start allocating or it would require the list to grow to be able to cache the MemoryManager reference, neither of which we'd want.)

[Neme12]

Why would it have to bake in the notion of it being a T[]? I don't understand. Memory<T> is an abstraction.

[Neme12]

I understand that it's possible to get the underlying array from a Memory<T>, but only via MemoryMarshal and anyone who does that and relies on it being an array could be expected to be broken IMO. That's akin to people using reflection to get the backing array.

[stephentoub]

Because Memory<T> is backed by either T[] or a MemoryManager<T>, and we wouldn't use MemoryManager<T> for the reasons I mentioned.

[Neme12]

But that would be an implementation detail. The API would still return an abstraction.

[stephentoub]

Let's say List<T> changed to be backed by something other than T[]. What "implementation detail" would you then employ to keep this new AsMemory functional, fast, and allocation-free?

[Neme12]

I mean I wouldn't have the expectation that it has to be 100% allocation free. I would expect that the data wouldn't be copied so that I could use this with huge data sets, but a small allocation just for the memory manager seems fine IMO.

[stephentoub]

I mean I wouldn't have the expectation that it has to be 100% allocation free

It's a key expectation in general for this kind of method, that it's effectively a cheap, allocation-free cast.

[DaZombieKiller]

The use case presented in the OP seems like it would be better served by an IBufferWriter<T> implementation for List<T>. That's a whole can of worms of its own, though.

[Neme12]

I mean I wouldn't have the expectation that it has to be 100% allocation free

It's a key expectation in general for this kind of method, that it's effectively a cheap, allocation-free cast.

I guess we have different expectations. Whenever I'm using Memory<T>, I'm aware that there might be a small allocation there for the MemoryManager since Memory<T> can be backed by that.