CollectionsMarshal.AsMemory for List<T>

[lorenzrox]

Hello,
in the software I'm working on we use ReadOnlyMemory<T> to pass around collections of readonly structs to some async methods to take advantage of ref enumerators and accessors.
Very often those ReadOnlyMemory<T> are created starting from List<T> and getting a T[] out of it uaing the ToArray method. Since this step allocates an unecessary array each time, I was looking for some method to get a Memory<T> (or ReadOnlyMemory<T>) from the List<T> itself the same way CollectionsMarshal.AsSpan does for Span<T>? I'd like to avoid creating an overload taking a List<T> for each async method...
Has CollectionsMarshal.AsMemory ever been considered? Is there any downside having such method?
Also, is taking a ReadOnlyMemory<T> instead of IEnumerable<T> or IReadOnlyList<T> really worth the additional allocation of a T[]?

[huoyaoyuan]

It should be more risky than AsSpan. The marshaled span isn't meant to be persisted, since resizing the list can garble it.

If you are referencing a "list" that won't change after, ImmutableArray would probably be better.

[sfiruch]

This has been suggested repeatedly before, see #90141, #101914 and #105179.

While I too think this would be a useful addition, @stephentoub and @tannergooding disagree, citing the following reasons:

1. Memory<T> has a potentially much longer lifetime compared to Span<T>. This increases the risk that it will point to stale data. Obviously, this is only an issue if you keep the List<T> reference around.
2. Apparently, "It's a key expectation in general for this kind of method, that it's effectively a cheap, allocation-free cast.", while it might allocate. Don't know who holds that expectation, and why.
3. Memory would force the backing storage of List to be an array. In the API review it was pointed out that changing the backing store of List is utterly unrealistic.

But it doesn't matter all that much. .NET 9 allows Span to be used in many more places, reducing the need for Memory. Additionally, you can easily create an extension method yourself:

public static Memory<T> AsMemory<T>(this List<T> _list)
{
#if NET9_0_OR_GREATER
    [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_items")]
    extern static ref T[] GetListItems(List<T> list);

    var items = GetListItems(_list);
#else
    var items = (T[])_list.GetType().GetField("_items", BindingFlags.NonPublic | BindingFlags.Instance)!.GetValue(_list)!;
#endif

    return new Memory<T>(items, 0, _list.Count);
}

[sfiruch]

But, any addition operation of the original list can invalidate the span or memory. Span has much more restricted lifetime and makes it less possible.

The Span/Memory safety delineation strikes me as very arbitrary, in a language that allows me to play with pointers, let me access private fields or change readonly fields via reflection, etc.. In my mind the different lifetimes doesn't make that much of a difference. It's not even a memory safety issue. I enjoy using C# precisely because it allows me to do things like unaligned vector loads when I want to. Using that functionality means I voluntarily give up multiple guarantees. This can be seen as slippery slope.

However, by providing .AsSpan() you've already settled the debate one way. Not allowing .AsMemory() feels inconsistent. But you do you :)

[tannergooding]

The ability to do something and the safety/guarantees of doing those things are very different and important.

Accessing private fields and changing readonly fields via reflection are examples of code that you can write, but which is strictly undefined behavior. It can fail in arbitrary ways and what works today may no longer work in the next version of .NET or when run on another computer or a separate invocation of the process, etc. -- Mutating certain static readonly fields via reflection is actually an example of something that was made to deterministically throw in modern .NET

Span gives access to lowlevel fundamentals without overly restricting our own implementation and future directions we may want to take the code. Exposing AsMemory does not provide that same benefit, it would overly restrict the ability to version our code for an extremely rare scenario that can be handled in several alternative ways.

We have to balance what we expose to ensure that we can give users access to core functionality without giving up our own flexibility.

[sfiruch]

I understand your arguments. For my use case with functions that modify List<T> or T[] this means that I either

• rely on reflection or private accessors,
• perform deep copies,
• or duplicate code

I chose the first option, for obvious reasons.

[tannergooding]

Notably you could also just pass ICollection<T> and do a very cheap typecheck, deciding whether to call CollectionsMarshal or .AsSpan() based on the type.

That's effectively what LINQ does

[En3Tho]

It is also easy to create a very simple interface like ISpanProvider and just wrap list/array/whatever. I don't think clinging to Memory<T> does you much good