[API Proposal]: Enable Inheriting from System.Array or Support for Custom Array-Like Types

[emphasis87]

Background and motivation

I'd like to request the ability to subclass arrays or define custom array-like types with the performance and syntax of native arrays ([]). This would enable scenarios where custom logic, metadata, or behavior is tied directly to the array structure itself, rather than using wrappers or parallel structures.

Motivation:
Currently, arrays in C# are sealed and cannot be extended. While System.Array is an abstract class, it is not possible to derive from it in user code. This limits the extensibility of array-like behavior. For example:

• Attaching metadata or custom indexing behavior to an array.
• Implementing bounds checking, logging, or change tracking directly in an array.
• Supporting custom memory layouts for high-performance scenarios.

Workarounds involve wrapping arrays in custom classes, which:

• Adds an extra layer of indirection.
• Breaks compatibility with APIs expecting T[].
• Loses the syntactic and performance benefits of raw arrays.

API Proposal

public class CustomArray<T> : System.Array
{
  // ..custom data and implementation
}

API Usage

public class CustomArray<T> : System.Array
{
}

var c = new CustomArray<string>(32);
c[0] = "Hello";

string[] other = c;
Console.WriteLine(other[0]); // should print "Hello"

Alternative Designs

A dynamically (or statically) sized inlined array, syntax can be determined later.

public class CustomArray<T>
{
  // not sure how to plug a variable for determining the size of the array
  public ref int[] MyCustomInlinedArray; // not possible to store into int[] reference
}

var c = new CustomArray<string>(32);
c.MyCustomInlinedArray[0] = "Hello World";
var span = c.MyCustomInlinedArray.AsSpan();

Risks

No response

[huoyaoyuan]

This would enable scenarios where custom logic, metadata, or behavior is tied directly to the array structure itself, rather than using wrappers or parallel structures.

This is not actionable. Arrays as well as strings are specially handled in many components, from GC to JIT, because they are variable length objects.

Supporting more variable length objects isn't totally impossible, but it's very impractical given the impact range.

[emphasis87]

Can you elaborate? This does not exactly tell me much. What concrete issues, at least as an example, can you identify?

strings are specially handled

If the casting is the issue, that can be ommited. I am specifically interested in having additional data in the array.

Our use case is that we have to mark an array as locked and later read the value. Transfering the value around separately is not exactly feasible.

From a naive perspective, this would be very easy in C/C++.

[emphasis87]

Why I thought that is would be feasible:
I imagined the implementation as having a reference to the concrete array type, and afte that directly the items buffer. This does not infer that you can not have additional metadata after the type reference, since you have to have the exact pointer to the items array anyway, or the data can be stored after the buffer.

[neon-sunset]

You can wrap an underlying array in a struct. That's what ImmutableArray<T> does.

[emphasis87]

You can wrap an underlying array in a struct. That's what ImmutableArray does.

I know I can. That is not what I am asking for though. Manipulating structs brings with it its own set of issues, like boxing, and overall code cumbersomeness and also the issue of maintaing the data in sync with the attached array.

[huoyaoyuan]

Can you elaborate? This does not exactly tell me much. What concrete issues, at least as an example, can you identify?

For example, GC needs to precisely recognize which fields are references in an object. Currently fixed sized objects are encoded by field offsets, and arrays are recognized as a range of references for elements. There's no way to encode a mixture of these.

From a naive perspective, this would be very easy in C/C++.

C++ doesn't have a type system nor GC. It can manipulate object layout much more arbitrarily.

[huoyaoyuan]

Our use case is that we have to mark an array as locked and later read the value. Transfering the value around separately is not exactly feasible.

Usage-wise, how would you ensure the correctness around reading the array?
If you are passing array objects around, there's no way to make other code respecting your custom mark.
If you are passing specialized type around, then ImmutableArray<T> already fulfills the usage.

[emphasis87]

there's no way to make other code respecting your custom mark

I never expected other code to respect it.

If you are passing specialized type around, then ImmutableArray already fulfills the usage.

The use case is little bit more complicated then ImmutableArray, it allows inserting after certain position in the array, but not before, basically COW with safe future enumeration.

GC needs to precisely recognize which fields are references in an object. Currently fixed sized objects are encoded by field offsets, and arrays are recognized as a range of references for elements. There's no way to encode a mixture of these.

Ok, that sounds like a problem. Would value types not owning a refence work then? Even having bool and int fields would help in many cases. Or is that still infeasible amount of work?

[huoyaoyuan]

Ok, that sounds like a problem. Would value types not owning a refence work then? Even having bool and int fields would help in many cases. Or is that still infeasible amount of work?

It requires every part in the ecosystem to adapt the new layout, which is nearly impossible. External components like debugger would also have assumptions around memory layout of array.

A custom struct of (int, Array) would be the most efficient approach, just like ArraySegment<T>. The only thing you lose is atomicity when assigning into a field.

[emphasis87]

Ok, makes sense.

Can we reduce it to supporting an array-like type, as in, not directly inherited from System.Array, but with the same interfaces, an indexer and possibly providing Span<T>.

I guess what I am asking is for dynamically sized classes, which in it's own way would be hard.

Perhaps inlining an array of a fixed size in a class would be doable, since there is a similar proposal for inlining into a struct. It would help, but still would require a lot of code overhead.

I know I can do it currently with other value tuples or custom structs, but that is not really what I am after.

[huoyaoyuan]

Can we reduce it to supporting an array-like type, as in, not directly inherited from System.Array, but with the same interfaces, an indexer and possibly providing Span<T>.

I guess what I am asking is for dynamically sized classes, which in it's own way would be hard.

It's as hard as the original post. It can be even harder because the variable length objects are having strong constraints from JIT and GC.

Perhaps inlining an array of a fixed size in a class would be doable, since there is a similar proposal for inlining into a struct.

A struct field is always fixed-size. Variable-length is really a monster for type system, and it's only achieved for critical, fundamental cases.

[Sergio0694]

"I am specifically interested in having additional data in the array."

Throwing one more possible approach in here: literally just use a conditional weak table. Put that behind an extension method, or even behind some extension properties if you're feeling fancy and you're using C# preview. And then you have arrays where you can read and set arbitrary properties, if you really want to.

Or, just rethink your architecture. The fact you specifically need this makes me think something else is not really well structured in the code around it.