-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Api Proposal] Add List<T> AsSpan to CollectionsMarshal #27061
Comments
I do not think this should be on MemoryMarshal. This should be on a new one, like CollectionsMarshal. This should not be an extension method. No other methods on The PowerCollections in corefxlab would be a good place to experiment with this: dotnet/corefxlab#2406 |
Updated
Would then need to go via private reflection? |
@jkotas is reflection what you have in mind? @benaadams curious, do you happen to have a motivating scenario? |
|
I had in mind all the different list and array builders in "Common". They are all variants of List with different performance characteristics. |
All |
Would it make sense to propose a "ListBuilder"/"SpanBuilder" type then? It could have roughly the same surface area as List, along with an |
@safern this does not seem to me essential in order to ship 3.0. Please correct me if I'm wrong. |
any updates, just wondering? Sounds like a great API 😃 |
@benaadams We understand that this a logical extension of the current implementation of the type. Could you list some compelling scenarios? We can always come up with potential scenarios. |
Creating a Memory/Span (Array-like) of an unknown upfront size. The alternative would be to expose an alternative builder type https://github.com/dotnet/corefx/issues/31597#issuecomment-413059736 |
FYI, it's currently being discussed here. |
I missed this when I had a list and wanted to do something (been a while... can't remember what the exact situation was) which could be vectorised (since you need to take pointer of the underlying array). It didn't have to be exposed as a Span... but just my thought. |
Approved shape: namespace System.Runtime.InteropServices
{
public partial static class CollectionsMarshal
{
public static Span<T> AsSpan(List<T> list);
public static ReadOnlySpan<T> AsReadOnlySpan(List<T> list);
// We don't want this one:
// public Memory<T> AsMemory(List<T> list);
}
} |
Re-opening until API is exposed from the ref assembly. |
The “approved shape” wasn’t completely implemented with dotnet/coreclr#26867. Should we update the “approved shape” above so it is in sync with the code? |
Re-flagging as api-ready-for-review to address the AsReadOnlySpan change and also do a quick review on the nullable annotations change (see dotnet/coreclr#26903). namespace System.Runtime.InteropServices
{
public partial static class CollectionsMarshal
{
// Updated with nullable annotation
public static Span<T> AsSpan(List<T>? list);
// Since the AsSpan(...) overload is no longer changing the internal version,
// we don't need this one anymore
// public static ReadOnlySpan<T> AsReadOnlySpan(List<T> list);
// We don't want this one:
// public Memory<T> AsMemory(List<T> list);
}
} |
We decided to not increment the version, which is why we removed the namespace System.Runtime.InteropServices
{
public partial static class CollectionsMarshal
{
public static Span<T> AsSpan(List<T>? list);
}
} |
Its not a "safe" operation, though it is a useful one to gain access to the prebuilt array; without first copying using
.ToArray()
/cc @jkotas
The text was updated successfully, but these errors were encountered: