readonly members on interfaces

[IS4Code]

I think readonly members as introduced in C# 8.0 (#1710) should be usable on members of interfaces as well. The main reason is in this example:

public interface IVector<TVector> where TVector : struct, IVector<TVector>
{
    readonly TVector Add(in TVector other);
}

TVector Add(in TVector a, in TVector b) where TVector : struct, IVector<TVector>
{
    return a.Add(b); // shouldn't cause copying
}

If readonly members on interfaces aren't available, there is no way to make a generic method for vector adding (or other operations) without copying. This is extremely useful once you start working with larger structures that are composed of multiple smaller types (like vectors and matrices). For example, if Vector contains 4 float values, Vector<Vector> then contains 8 values, Vector<Vector<Vector>> 16 values; each containing two fields of the inner type:

public readonly struct Vector<TInner> where TInner : struct, IVector<TInner>
{
    readonly TInner first;
    readonly TInner second;

    public readonly Vector<TInner> Add(in Vector<TInner> other)
    {
        return new Vector<TInner>(first.Add(other.first), second.Add(other.second)));
    }
}

Without readonly on IVector<TVector>.Add, this code must copy first and second before calling Add on the inner type, and there is no other way without abandoing readonly and in at all to prevent this, other than providing a separate object for operations with TVector Add(in TVector, in TVector) method, at the cost of a virtual call. Marking the interface method readonly means that the compiler knows the in parameter will not be modified (at least by an implementation in C#).

readonly should be allowed on interface members to indicate that the implementing method must honor readonly as well. Then, if the implementing type is a struct, it must implement any readonly method with another readonly method. The other way around should be possible though, i.e. implementing a non-readonly method by a readonly one.

Relation to classes and #3885

Calling a readonly method on structs already has a well-defined meaning: this won't be modified from inside of the method. This is the meaning that is extended here to interfaces, but classes cannot change the value of this, so in essence all methods are implicitly externally readonly. A class can therefore freely implement an interface with readonly methods without caring about readonly anywhere in the implementation, because this will never be modified. A readonly variable of a reference type never requires creating a defensive copy when calling any of its methods, and is a non-issue if used in the example above.

This proposal is, for the most part, unrelated to #3885, but what needs to be resolved is whether readonly on an interface should denote external readonlyness (this is not observably modified) or internal readonlyness (can't write to fields and call non-readonly methods). Value types share both meanings, because there is no indirection that could separate them. It seems that classes could only have internal readonlyness, unless a C++-style const reference to an object is considered, but then it would warrant a new keyword anyway.

For that reason, even if readonly class was added, the relation to interfaces would still be the same: a class implementing an interface with a readonly method doesn't have to care about upholding readonly on that particular method, because its can never be differentiated from the point of the interface.

[DaZombieKiller]

I believe readonly members would need to be allowed on class types before this could happen.

[IS4Code]

@DaZombieKiller That might not be necessary. There is no real benefit to a readonly class or a class method, as it doesn't have to be pure anyway, and there is no such thing as a readonly object or reference to it. So readonly can be specifiable on classes with the same rules as for structs, or not, and then you would be able to implement a readonly interface method with a non-readonly one in a class.

I am for the second option. If people start placing readonly on classes or their methods because they think the code is safer or faster that way, that only shows a misunderstanding of the keyword. Make it explicit that having a readonly interface member is there only for implementing structs, and classes could ignore it.

[jaredpar]

Sounds like the request is roughly the following:

1. Allow the readonly modifier to appear on interface member declarations.
2. When a struct implements an interface where members have the readonly modifier, the matching methods on the struct must also have readonly. Or the declaration must be a readonly struct which implies readonly on every member
3. When a readonly member is invoked on a value which is a type parameter than is also constrained to be a struct then elide copies where you would elide them for readonly members on a struct.

That's a reasonable extension of the readonly feature. It's also a request that I've seen before (with slightly different semantics). I'm unsure if there are enough places that this would be useful to justify doing it.

Consider that when we did the readonly struct feature originally we talked about allowing individual members also be marked as readonly. That was not done though, in part, because we couldn't find enough types / data to justify adding that extra level of granularity. After we released readonly struct though developers provided enough examples that we felt it was worth the extra level of granularity and concept count to the language.

I think we'd need to see similar examples or patterns to get this through LDM.

I believe readonly members would need to be allowed on class types before this could happen.

Not necessarily. The readonly member feature is specific to struct types. The rules could just be written to ignore readonly when implementing the interface on a non-struct type.

[IS4Code]

@jaredpar Yes, that is pretty much it. Not sure about others, but I have stumbled upon this when doing what was pretty much my initial example. It would also give this issue a reason to be resolved.

[DavidArno]

I believe readonly members would need to be allowed on class types before this could happen.

Not necessarily. The readonly member feature is specific to struct types. The rules could just be written to ignore readonly when implementing the interface on a non-struct type.

This would create issues were readonly/pure classes ever to be implemented in the future. We'd have the situation where an interface could declare a readonly member, as could a class. But there'd either be no requirement for the class to respect the readonly requirement of the interface, or you'd have to make a massive breaking change to enforce that contract causing existing code to fail.

[HaloFour]

@DavidArno

IMO readonly already means something other than "pure" in the C# language so I doubt any such feature would be based on that keyword.

[IS4Code]

@DavidArno
The whole concept of readonly is to prevent a location from being modified. readonly structs and methods are here to allow operating on read-only data without having to create a defensive copy each time, as the compiler must ensure that even though it produces unverifiable code (loading the address of a read-only field), the code is still valid. There is no such thing for classes – the object's mutability is governed purely by its implementation, and having a readonly (private) field in a class or readonly method is as useful as having a readonly local variable or a parameter – to make sure that you don't modify it.

There is nothing like a readonly object neither in the language nor in the runtime, there is no mechanism for producing the defensive copy of an object, and most importantly, readonly can be completely bypassed if you move your class's storage (to another object or a dictionary, for example).

Concepts like "read-only" and "pure" are independent on each other, and aren't even in any subset relation. Something to indicate mutability (the observable state of the object is not modified) or purity (the observable state of anything is not modified) could be useful in the future, but it's not related to readonly.

[DavidArno]

There is nothing like a readonly object neither in the language nor in the runtime...

And there was nothing like a readonly struct before the concept was introduced.

Immutable types (ie ones that go beyond having read-only class fields where the ref can't change to guaranteeing the content of the things pointed to by those refs are read-only too) would be a useful addition to the language. Likewise having read-only methods that do not change the (direct) value of the object's state would also be useful (you are right that these aren't quite pure methods as they cannot guarantee no side effects without truly immutable types).

This might never happen of course as there are so many other features vying for the language team's attention. But it would be disappointing to see this effectively ruled out completely simply because a change was made to support structs that then rendered it so much harder to implement read-only/immutable classes in future.

[jaredpar]

I doubt that we would ever add readonly to class types in the future because it really has no inherent value. The value proposition for struct is quantifiable: type states implementation detail as contract so consumers can avoid introducing unnecessary defensive copies. The value proposition for class would be: type states implementation detail. Not really a big seller.

The reason is that readonly is a shallow guarantee. That's true even for struct as a struct nested in another struct is really just putting a name on a group of fields. The readonly of the containing struct ends up dominating the design of the nested struct. That has the bonus though that we can avoid defensive copies with a single readonly on the containing type.

The shallow guarantee for a class though doesn't really provide any value. What does it matter if a method implementation in a class modifies it's immediate field vs. a nested field? To the consumer it's still a modification and there is no specific optimizations or really any semantic changes you could make based on that information.

If we added a modifier to class it is much more likely to be immutable. That is essentially the readonly guarantee but deep., Meaning an immutable type can only contain other types which are immutable. That is a meaningful guarantee that consumers can optimize around.

[IS4Code]

Just an example of how readonly on classes can be bypassed.

readonly class Class
{
    readonly StorageClass storage = new StorageClass();

    public int Property {
        get {
            return storage.Property;
        }
        set {
            storage.Property = value;
        }
    }

    class StorageClass
    {
        public int Property;
    }
}

[DavidArno]

@IllidanS4,

Just an example of how readonly on structs can be bypassed:

    readonly struct Struct
    {
        readonly StorageClass storage;

        public int Property {
            get {
                return storage.Property;
            }
            set {
                storage.Property = value;
            }
        }

        class StorageClass
        {
            public int Property;
        }
    }

As I previously mentioned, immutable types, that do not permit such bypassing, would be a useful addition to the language. That could be achieved by only allowing readonly types to be used within a readonly class. But this would create inconsistencies with readonly structs and the latter could still be used to bypass the restriction via the above example.

As @jaredpar mentioned, a new keyword - eg immutable will likely be needed for types and fields to indicate that not only is the reference immutable, but the entire type - all the way down - is immutable too. Just as it sometimes makes sense now to mark a non-read-only struct's methods as readonly, so that existing keyword could be used to denote that a class method doesn't access mutable state either.

So therefore, introducing readonly methods to interfaces before the whole subject of immutable types has been thought through risks making immutable types more difficult to implement.

[IS4Code]

Thinking about it, externally readonly method means "this method will not modify the variable where it is called". In this sense, all class methods are readonly as the this reference itself will never be modified.

This is especially apparent with generics:

public static string TestFormat<T>(in T arg) where T : IFormattable
{
    return arg.ToString(null, null);
}

The compiler has to ensure that the value of arg shall never be modified, so under the hood it creates a defensive copy. However, this doesn't have to happen in two cases: if T is constrained to a class, so arg is an object reference and thus can be modified only by direct assignment to arg; or if IFormattable.ToString is declared readonly. If both are true, readonly is superfluous, so technically all reference types are already readonly (in the terms of references to their instances). This also means that if where T : readonly is introduced in the future, it should match readonly structs but also all classes.

[jaredpar]

Just an example of how readonly on structs can be bypassed:

This doesn't bypass readonly on a struct though. The readonly modifier, both on the struct declaration and in storage locations such as fields, describes the state of the memory / location of the fields. Specifically that the location cannot be altered through that reference.

The readonly modifier was never intended to protect against modifications to reference types that were reachable from a struct. That is true all the way back to C# 1.0.

Saying that this approach bypasses readonly requires an incorrect definition of the feature.