compile-time readonly arrays, const T[]

[MkazemAkhgary]

Allow arrays marked as const will have get only indexer. the set[] is prevented at compile time, after compilation readonly arrays are exactly as same as normal arrays.

This is not something that should be (or even could be) controlled in runtime. This keyword has same semantics of readonly keyword but for elements of array.

though this might require changes in CRL but Imho it worth the feature.

(the syntax is just proposed, but could be anything that describes the behavior.)

ReadOnly collection wrappers always occupy an extra reference, when you have thousands of small byte arrays, having read only wrappers doesn't sound optimal, especially when those bytes are smaller that 8 or 4 bytes, so you drop the readonly wrapper thing from your code to remove extra reference overhead, but then you are not sure of array immutability in your code.

read only wrappers are not language feature, in my opinion c# is really missing readonly array feature.

why not add const keyword especial meaning for arrays and call it a day?

• const T[] is assignable, but does not have setter (this is prohibited in compile time)
• const T[] is not assignable to T[]
• T[] is always assignable to const T[] by reference. so as long as there is reference to T[] changes will also change const T[].
• const T[] can be used in local/field variable declarations, method and delegate parameters, generics and type parameters
• const T[] and ref T[] are mutually exclusive so they cant be used together.
• readonly const T[] is readonly by index and by reference.
• unsafe pointer to const array could be retrieved, but if pointer be const also or not (like in c++) has room for discussion.

const T[] declaration/initialization and assignments

var immutable = new const int[5]; // could be allowed, although items are always 0.
var immutable = new const int[3]{ 1, 2, 3 };
var immutable = new const int[]{ 1, 2, 3 };
var immutable = new const[] { 1, 2, 3};

var immutable = (const int[])array; // cast T[] to const T[].
var mutable = (int[])immutable; // not allowed
var newArray = (int[])immutable.Clone(); // no problem

const int[] immutable = new[] { 1, 2, 3}; // normal array assigned to readonly array.
const int[] immutable = { 1, 2, 3};

int[] array = {1, 2, 3};
const int[] getonly = array;
getonly[0] = 4; // not allowed
array[0] = 4; // allowed and will also change getonly since references are same.
array = null; // reference is lost. getonly content can no longer be changed in static code.
getonly = new []{1,2}; // reference is assignable. only indexer is get-only.

Fields, const[] and readonly.

public class Foo
{
     public readonly const int[] FirstFewPrimes;

     public Foo()
     {
          FirstFewPrimes = new const int[] { 2, 3, 5, 7, 11, 13 };
          // after this, neither reference or contents of array is assignable.
          // IMPORTANT: Only at compile time. in runtime anything can be changed.
     }
}

const T[] Property:

public const byte[] Data { get; private set; } // data is privately assignable but array indexer is get only.

public void Foo()
{
    byte[] arr = new byte[3];
    Read(arr);
    Data = arr; // this is assignable
    arr[0] = 0; // will also change Data since references are same
}

const T[] method parameters and generic methods

Again iterating over same thing, const[] returns, parameters and generic parameters and inside delegates would be also possible

public void Foo<T>(T data) // Foo(new const int[] {1,2,3});  would be possible
public void Foo<T>(const T[] data) // Foo(new const T[] {x,y,z});  would be possible
public const T[] Foo<T>(); // Foo<int>(); would be possible
// other examples with delegates etc...

type parameters

this could be also used inside type parameters when initializing a generic class. because when declaring T it does not matter if its const int[] or int[]. in static code, you are doing operations with T

// stupid example, enumerable of 10 const arrays referencing the same thing. 
// but purpose is only to show const[] is also valid in type parameters.
IEnumerable<const int[]> x = Enumerable<const int[]>.Repeat(new const int[1], 10);

[tannergooding]

This would probably conflict with the most likely syntax for blittable constants: #688.

C/C++ has a few different syntaxes for this.

Mutable Pointer and Mutable Contents

• T*

Mutable Pointer and Immutable Contents

• T const*
• const T*
• const T const*

Immutable Pointer and Mutable Contents

• T* const

Immutable Pointer and Immutable Contents

• const T* const

I would think, if C# were to expose it, we would want a way to expose each level of immutability as well.

Mutable Array and Mutable Contents

• T[]

Mutable Array and Immutable Contents

• T readonly[]

Immutable Array and Mutable Contents

• readonly T[]

Immutable Array and Immutable Contents

• readonly T readonly[] (or maybe immutable T[])

[svick]

ReadOnly collection wrappers always occupy an extra reference, when you have thousands of small byte arrays, having read only wrappers doesn't sound optimal, especially when those bytes are smaller that 8 or 4 bytes, so you drop the readonly wrapper thing from your code to remove extra reference overhead, but then you are not sure of array immutability in your code.

What about a struct read-only collection wrapper, like ImmutableArray<T>? With that, there is no extra reference.

read only wrappers are not language feature, in my opinion c# is really missing readonly array feature.

Why should this be a language feature? Usually, those are reserved for things that can't be done with a library.

[MkazemAkhgary]

@svick ImmutableArray has boxing and unboxing problem (even though it could be rare), but it cant be done with a library to achieve true readonly array.

good to know that such thing exist, I'm going to use them.

[HaloFour]

How would these "arrays" be implemented? Without a facility to support such a thing in the CLR at best you'd have some kind of wrapper, but you couldn't treat that wrapper as an array.

[tannergooding]

@HaloFour, I would guess, at best, the language would provide some tracking (this is all C/C++ does and is really all C# does for ref readonly locals as well).

That being said, a struct wrapper is probably good enough for most cases.

[MkazemAkhgary]

Also initializing ImmutableArray creates garbage in process. the IEnumerable. though single instance of a special IEnumerable could be used where you can change its state to enumerate new data. (and that also uses single enumerator instance)

[yaakov-h]

@MkazemAkhgary What's the "garbage" IEnumerable that gets created?

[MkazemAkhgary]

@yaakov-h ToImmutableArray accepts an IEnumerable only, I don't know way of iterating over it without creating short lived objects. except the only way I know that is reusing the instance. yes Gen0 are collected fast. but I'm trying to cover this discussion in different aspects.

[MkazemAkhgary]

How would these "arrays" be implemented?

@HaloFour the same way as readonly keyword is implemented, as I said, it only makes sense at compile time.

[yaakov-h]

@MkazemAkhgary ImmutableArray.Create(...) and ImmutableArray<T>.Builder both exist.

[MkazemAkhgary]

@yaakov-h thank you so much, did not know such thing exist. hmm my arrays are also less that length of 4 so I can really pass parameters without creating any temporary array.

[HaloFour]

@MkazemAkhgary

the same way as readonly keyword is implemented

Under what circumstance? Normally readonly as it applies to fields is a flag set by the compiler and enforced by the CLR, at least to the extent that normal trusted code is not permitted to directly update that field. The CLR lacks a mechanism to do anything like that with arbitrary array instances, especially as they can be passed around by reference to methods which are unaware of their immutability.

Or are you referring to readonly ref which I believe has been renamed to in? That is strictly compiler enforced and perhaps a better candidate. The array itself would be your normal mutable array, but by the way you declare it and the way you pass it to other methods you rely on a convention in the compiler to not allow the array to be mutated. However, lacking CLR enforcement there's still the potential that the array could be modified by an errant actor.

[alrz]

@HaloFour: at best you'd have some kind of wrapper, but you couldn't treat that wrapper as an array.

Plus the compiler couldn't rewrite foreach as a for.

Note: this is a reduced version of #421.

[tannergooding]

I also think that compiler only validation is probably "good enough" for most cases (even with runtime "enforcement", said enforcement can generally be broken via unsafe).

One of the few issues comes up if the user wants to directly expose the array and another language wants to consume it, but that could probably be handled via 'modreq' (in the same manner as ref readonly).

[4creators]

IMHO it is another proposal going around some sort of value/object/array/references/pointers immutability at runtime and at compile time. For me it amounts to growing community desire to get it sorted out at the level of languages and framework (CIL, Jit). Therefore I would like to propose a bit more generalized solution where C#/VB/F# (F# being obviously the easiest case) would support notion of:

• runtime defined (transient) immutability indicated via readonly keyword which can be revoked via conversion
• compile time defined (or real) immutability indicated via const keyword which can not be revoked

Than declaration of array could look like after @tannergooding :

// Mutable Array and Mutable Contents
T[]

// Mutable Array and Immutable Contents
T readonly[]

// Immutable Array and Mutable Contents
readonly T[]

// Immutable Array and Immutable Contents
readonly T readonly[] (or maybe immutable T[])

// Explicit conversion required
T[] = (T[]) readonly T[];

// Mutable Array and Constant Contents
T const[]

// Const Array and Mutable Contents
const T[]

// Const Array and Const Contents
const T const[]

// Explicit conversion fails
// Error: cannot convert const Array to readonly Array - conversion from const to readonly type not allowed
readonly T[] = (readonly T[]) const T[];   

From language compiler perspective enforcement of the above syntax is straightforward - one can look at my const parameters prototype here https://github.com/dotnetrt/roslyn/tree/features/constparameters

At IL and runtime level it is possible to use modreq modifier jointly with an attribute. I am working on supporting const parameters feature via compiler generated IsCompileConstAttribute usage which would decompile to [modreq] System.Runtime.CompilerServices.IsCompileConstAttribute. Readonly ref structures already use and most probably ref readonly parameters will use [modreq] System.Runtime.CompilerServices.IsReadOnlyAttribute, C++ CLI uses [modreq] System.Runtime.CompilerServices.IsConst class with behavior different from [modreq] IsReadOnly. Altogether runtime and compilers get ready to support even the most complex immutability features.

AFAIR there was some recent work in academia on efficient runtime implementations of WriteBarriers for garbage collected languages which support transient immutability universally for all objects at low cost (one bit "flag") and most probably such mechanism could be implemented in dotnet.

However the picture gets really complex when you go through the rabbit hole. One first has to solve problems of type equivalence:

• is const T[] == readonly T[],
• which conversions between different immutable types are allowed,
• how immutable types behave during overload resolution?
• how immutable types can be used as generic type parameters?
• what kind of generic constraints could be allowed specifically for immutable types?

imho this is one of the areas in dotnet which is slowly becoming a low hanging fruit worth putting some work into eating it.

just my 3 cents

[Pzixel]

IIRC IL even doesn't have opcodes to load data from constants becuase they have to be inlined by compiler. Thus const array is unusable because we just don't have opcodes to do it.

Of course, we can emulate it via static readonly, but that's what we already can do today.

[MkazemAkhgary]

You probably misunderstood. I didnt say const is constant. In this proposal const keyword refers to readonly array. Not constant array

Maybe i choosed wrong keyword. The comment below proposal suggests readonly keywords which is good.

[4creators]

Thus const array is unusable because we just don't have opcodes to do it.

@Pzixel That is obviously not true as usability is a distinct term from runtime support. Significant number of new language features requires runtime changes what has nothing to do with their usability.

If you say something is unusable bcs there are no reasonable use cases than it can be at least discussed.

[tannergooding]

@Pzixel, the IL has support for a thing called "Data Declarations" which is (essentially) compile time structured data that is consumed by runtime. This could be used to support actual blittable constants (#688) or UTF8 string literals (#909).

[IanKemp]

Guess this is never happening then...

[CyrusNajmabadi]

@IanKemp the bed for this seems minimal, esp with the availability of types like ReadOnlySpan.

[Pzixel]

We need WPO and parial evaluation to make things smoother. But I think it's outside C# LDM goals.