Contagious Read-Only Type

[YT-GameMaker]

Typically, a type needs to restrict intentions that modify its state, but no need to restrict intentions that read its state. Therefore, we often write some read-only properties and methods. However, these read-only properties and methods should not return references to fields, as that would be unsafe. To address this, we have to clone fields or write more properties and methods to provide details about fields. In fact, if we can constrain callers to only access read-only members of returned references, there is no need to do these extra steps.

So, I came up with the concept of Read-only Type. Note that this is unrelated to readonly struct and is also unrelated to readonly class (which currently does not exist). Consider this example:

class Item
{
    public int x;
    public object y;
}

class MyClass
{
    List<Item> _items;

    // OK, regular type can be converted to readonly type
    public readonly List<Item> Items => _items;
}

Here, readonly List<Item> acts as a type that includes all the read-only members of List<Item>. But at runtime, it is equivalent to List<Item>.

More details (Edit: there are some changes later on):

MyClass m = new();

// Error, readonly type can not be converted to regular type, except for unmanaged types
// var items = m.Items;

// OK
readonly var items = m.Items;

// Error, regular member of readonly type can not be accessed
// items.Remove(null);

// OK, readonly member of readonly type can be accessed (Note the return type is unmanaged)
int index = items.IndexOf(null);

// Error, return type of member of readonly type is readonly type, except for unmanaged return types
// Item item = items[0];

// OK
readonly Item item = items[0];

// Error, can not set field of readonly type
// item.x = 42;

// OK, cloning unmanaged struct is safe
int x = item.x;

// Error, cloning reference is not safe
// var y = item.y;

// OK
readonly var y = item.y;

// Error, readonly type can not be converted to regular type
// Item y2 = y as Item;

// OK, readonly type can be converted to readonly type
readonly Item y2 = y as readonly Item;

// Declaring parameter type as readonly type can make method more applicable
static int Sum(readonly int[] nums)
{
    int result = 0;
    //...
    return result;
}

int[] nums1 = new int[5];
readonly var nums2 = nums1;
Sum(nums1);  // OK
Sum(nums2);  // OK

As you can see, read-only type has a contagious nature, ensuring safety.

Perhaps it can go even further by directly exposing fields without the need for properties, something like this:

class MyClass
{
    public readonly | List<Item> Items;
}

<<<<<<<<<< EDIT >>>>>>>>>>

Due to the contagious nature of read-only types, the key is how to construct the first read-only type, without having to change our programming approach. We can continue to use readonly to mark certain properties and methods, as we do now (with the need to add support for class), indicating "this property or method will not modify this object." Then, we need to create the first read-only type. Here is the updated example.

class MyClass
{
    List<Item> _items;
    public (readonly List<Item>) Items => _items;
}

Note that a read-only type is returned here, which is different from the meaning of a readonly property. The read-only contagion starts from this return value. If we modify List<T> like this:

class List<T>
{
    public T this[int index]
    {
        readonly get { ... }
        set { ... }
    }

    public readonly int IndexOf(T item) { ... }
}

then we can start contagion：

MyClass m = new();
readonly Item item = m.Items[0];
// or
(readonly Item) item = m.Items[0];
// or
var item = m.Items[0];    // 'var' is 'readonly Item' here

readonly int index = item.IndexOf(null);
// or
int index = item.IndexOf(null);
// or
var index = item.IndexOf(null);    // 'var' is 'int' here, because it is unmanaged

We haven't caused any breaking changes. We can still use List<T> as before; the difference is that now, we can access its readonly members through readonly List<T>.

[HaloFour]

readonly already doesn't offer any guarantees of immutability within the C# language. I think you'd need a different keyword to indicate that intent. You also have the issue that no existing reference types advertise which members may or may not mutate internal state, so you'd have to include retrofitting the entire ecosystem otherwise you wouldn't be able to use any existing type with such a proposal.

[YT-GameMaker]

Yes, if this approach is feasible, adapting existing code would indeed be a significant task, but it could be done gradually. The most common needs might be related to arrays and collection types, those could be a starting point.

[theunrepentantgeek]

I think you're underestimating the amount of required worth by a factor of 100x or more - and for limited benefit.

Forking the .Net ecosystem will never be a good idea - 15 years (and counting) of pain experienced by the Python community shows why.

There are other proposals here that would provide much the same benefit without inflicting such cost.

[YT-GameMaker]

Please note modifications in the existing code, merely adding 'readonly' to some method parameters (to make them suitable for read-only types) and introducing some methods that return read-only types (to assist users in better understanding the internal state & allow used for read-only types). This does not involve breaking changes.

[yaakov-h]

This sounds an awful lot to me like System.Diagnostics.Contracts.PureAttribute, which could potentially be enforced today with an Analyzer.

[colejohnson66]

I think an attribute based approach is the best way to go about this.