Open DaZombieKiller opened 1 year ago
I would like to +1 the proposal and refer to the discussion in https://github.com/dotnet/runtime/issues/12221 for some motivation.
I'd like to add that creating a separate
LargeArray<T>
instead of resolving https://github.com/dotnet/runtime/issues/12221 only helps with cases directly affected byArray
limitations, instead of improving all other collections and interfaces using arrays as their underlying storage and/or exposing 32-bit indexers and lengths((I)(ReadOnly)List/(Hash)Set/Dictionary<T>
) at once.
Solving the large storage problem for the existing List<T>
etc is a non-goal for this proposal, this is about experimenting with a building block upon which types like LargeList<T>
, LargeSet<T>
, etc. could be built with the functionality available in the runtime today. Large storage is a pretty specialized scenario where separate "large" collections would most likely be better suited anyway, because they can optimize for larger sets of data (which is going to be a very rare case for the standard collections).
Would instead like to call it NativeArray
as the length matches the size of the native pointer.
To me, NativeArray
reads like it's backed by native memory, not that its length is limited to native int max 🤷♂️
Overview
Today, .NET does not support array dimensions larger than 0x7FFFFFC7. However, it is possible to implement a
LargeArray<T>
type by increasing the size of the array element (for example, an array ofT, T
tuples instead of an array ofT
s) or allocating a multi-dimensional array.API breakdown
Usage example
Breaking change?
No
API design questions
LargeArray<T>
provideint
,uint
, etc. indexer properties?LargeArray<T>
implementIEnumerable<T>
?CopyTo
equivalent)LargeArrayMarshal.CreateLargeArray
to perform validation on the input (element size, etc.)?GetHashCode
and equality?Additional context
A proof-of-concept implementation of
LargeArray<T>
by myself and @hamarb123 can be found here.Help us help you
Yes, but only if others can assist