Proposal: Allow fixed-size array embedded in class or struct (not need unsafe code)

[ygc369]

Copy from dotnet/roslyn#126
For example:

class A
{
    public object o[10];
}

struct B
{
    public int elem[100]; //not unsafe
}

[sharwell]

This would simplify the implementation of dotnet/corefx#1502, though currently I'm planning to create a value type which behaves like a fixed size array of length 8 and define fields of that type.

[tannergooding]

This has quite a bit of overlap with #78

[ygc369]

@sharwell
I want a fixed size array whose length could be user-defined, different sizes in different classes, not absolutely "fixed" anywhere.

@tannergooding
Not same as #78.
This proposal is more ambitious, the elements of the fixed size array can be any type, such as object, not only specific types.

[tannergooding]

@ygc369, I am aware, that's why I said it had overlap with and not that it was a duplicate :)

#78 would not require Runtime modification to support, while this one (which is effectively an extension of that) would require runtime modification to support, as I believe they are not currently configured to have managed objects not on the heap (although I remember some other thread related to allowing that, I just can't seem to find it atm).

[phi1010]

@ygc369: Does this suggestion aim at where in the memory the array is located or is it intended to be syntactic sugar, being equal to this:

class A
{
    public readonly object o[] = new object[10];
}

If it is intended to define where the array is actually stored, I'd rather prefer a CLR-compiler-independent optimization hint than a language feature here:

class A
{
    [ClrCompilerServices.TryToStoreThisArrayInTheObjectItself]
    public readonly object o[] = new object[10];
}

In case of readability, I don't like this suggestion, since I

• can't see that it is readonly
• it introduces a new way of achieving something, that only marginally longer code would also be able to achieve. The code itself get's shorter, but imo does not seem to reduce complexity, at the cost of forcing beginners to learn another language feature.
• it looks like C/C++, causing confusing notation of variable type (pointers, arrays as in char *mystring, myarray[5], mychar;) together with the variable name. If it is not readonly, it should be treated as a Type, thus be written as public object[10] o;

[ygc369]

@phi1010
It is intended to define where the array is actually stored.

[ygc369]

@sharwell @tannergooding
Any progress for this issue?

[tannergooding]

@ygc369, it's worth noting that #78 was updated to indicate that it should support any type. This is possible with ref returns.

Is there anything that this is still covering that #78 is not?