Ranges and indices of native int (or arbitrary size)

[lostmsu]

The current design of ranges and indices requires System.Range and System.Index types to be Int32 based thus further propagating inability to handle large massifs of data in C# with style.

In my scenario, Int32 limitation is hit when trying to slice or index large tensors. As instances of Tensor point to natively allocated memory that in most cases actually resides on GPU, their dimensions are not subject to the same unfortunate ~4GB size restriction imposed by .NET runtimes on regular .NET arrays allocated from .NET heap(s).

Unfortunately, the current design of the feature leaves absolutely no recourse for hacking around to get indices > 32 bit by explicitly requiring Int32.

I suggest C# language committee to consider extending index, ranges and slicing syntaxes to allow generic Index<T> and Range<T> types with the same public interface as the current Index and Range types with every use of Int32 (except GetHashCode) replaced with T.

Though the above option is highly preferred for forward compatibility reasons (smaller types for microcontrollers or larger than nint types for manipulating extremely large external databases, or simply manipulating 4+GB data from 32 bit .NET apps), it is also feasible to simply have NativeIndex and NativeRange types, that use nint instead of Int32.

Further, I'd be curious if the current language design process can be improved to avoid feature locks like this one.

[canton7]

I suggest C# language committee to consider extending index, ranges and slicing syntaxes to allow generic Index and Range types with the same public interface as the current Index and Range types with every use of Int32 (except GetHashCode) replaced with T.

Given that .NET can't do arithmetic operations on generic types, how would this and this work?

Also, slice syntax requires that the type being sliced implements a Slice method, or has an indexer which accepts a Range, or is a string or array (these are handled specially, using Substring and CompilerServices.GetSubArray respectively). In order to support Range<T>, all types which currently implement Slice(int, int) would also have to implement Slice<T>(T, T). But that Slice method would have to be able to cope with T being anything, which isn't really possible.

[lostmsu]

arithmetic operations on generic types

There are libraries, that provide that. I just started using Genumerics in my initial implementation attempt which claims native performance due to the fact, that JIT has to generate separate machine code for generics when used with value types. Even if it does not match perf 100% (I haven't checked), JIT can be improved to recognize the pattern, and generate better code.

would also have to implement Slice<T>(T, T)

No, that's not correct. All types will be free to implement Slice<T>(T, T) and/or Slice(TypeX, TypeX) for any TypeX they want to support.

[msedi]

Unfortunately, the current design of the feature leaves absolutely no recourse for hacking around to get indices > 32 bit by explicitly requiring Int32.

I'm having a similar problem with MemoryMappedFiles. Here I want to create a Span to the memory but only have Int32 to work with. It would be good to have a Span that supports 64-bit.

[lostmsu]

Span<T> is out of scope for this particular request.

[msedi]

@lostmsu: Somehow true, but somehow not. The request is about having ranges larger than int32. The request originally is about pointing into native memory where you need larger sizes than int32. As Span can also be used for native memory I assume the preferred way to point into native memory is using Span instead of working with pointers directly.

So in a sense you are right, it's not about Spans but it's about pointing to native memory.

You can also see some similar problems in the GetValue implementation of Array where you have an int32 and an int64 accessor.

[huoyaoyuan]

The ecosystem is quite strange here about lengths. The returning IL of array length is nint(you can see a cast inserted by C# compiler when accessing array length), but GC is limiting it to int32 since larger will be very hard or even impossible for GC. In contrast, other types are using int32 for length in IL, but they don't have such hard limit like GC managed array.