Allow "modifying" the return value of a property getter with readonly setters

[IS4Code]

At the moment, the language considers calling the setter of any property on a value type to be "modifying" the value, and thus disallows it when the value is returned by a method (including a property getter):

struct S
{
    public int Prop { get; set; }
}

static S SValue => default;

SValue.Prop = 10; // Cannot modify the return value of 'SValue' because it is not a variable

There is a good rationale for this restriction, as any modification done to the fields of the value type is not observed, and thus the code is likely a mistake (even though this could be a warning in my opinion since the setter could do much more than setting a field).

However, there are certain value types whose (settable) properties do not modify the state of the value type, such as ArraySegment (simplified):

public readonly struct ArraySegment<T>
{
    readonly T[]? _array;
    readonly int _offset, _count;
 
    public T this[int index]
    {
        get => _array![_offset + index];
        set => _array![_offset + index] = value;
    }
}

This means there is a certain lack of parity when accessing arrays through ArraySegment, as opposed to a Span for example which has a ref T this[int] indexer:

class MyClass
{
    readonly byte[] storage = new byte[10];

    public Span<byte> Storage => storage.AsSpan();

    public ArraySegment<byte> StorageSegment => storage;
}

var obj = new MyClass();
obj.Storage[0] = 10; // fine
obj.StorageSegment[0] = 10; // error - modifying return value

It seems this restriction has already been lifted once in regards to readonly value types, and that is if the value type is returned from a method (dotnet/csharpstandard#1277). I am proposing this to be allowed for all cases where a value type is returned, properties and methods alike, with likely the same reasoning as why it works for methods:

• The point of this restriction is to prevent assignment to fields of the value, such as when done directly through a field.
• By extension, modification through a property is likely to assign a field too (but the language cannot verify this).
• If the setter (or the struct) is readonly however, it provably cannot assign any fields of the value. This means that, for the setter to be sensible, it must have a side effect or indirect effect on an external value not contained directly within the value type (such as through a reference).
• Therefore there is no reason to prohibit the assignment ‒ the effect is exactly the same as if a reference type or a ref was returned, and the returned value type likely acts only as a wrapper of such a reference. It is possible the method returns a "copy" where any modifications would remain unobserved anyway, but that is possible for reference types too, and they are allowed in that situation.

In the example with MyClass, changing StorageSegment to a method "fixes" the error, but I don't feel it should be necessary there ‒ using a method miscommunicates the intention of having a "stable" property holding the actual value, while a method should be used when some sort of copying might happen. To me obj.GetStorageSegment()[0] = 10; looks much more "wrong" than obj.StorageSegment[0] = 10; which is natural in that situation and would work equally well.

[ufcpp]

Add readonly modifier on your setter.

var c = new C();
c.GetS().X = 2; // No error.

struct S(int[] array)
{
    public int X
    {
        get => array[0];
        readonly set => array[0] = value;
    }
}

class C
{
    private readonly S _s = new([1]);
    public S GetS() => _s;
}

[IS4Code]

Thank you for pointing out that this already works when the value is returned by a method ‒ I did not expect that difference and did not test that case. I have updated the post with using the return value of a property getter everywhere.

[ufcpp]

How about ref returns?

public readonly struct ArraySegment<T>(T[] array, int offset = 0)
{
    public ref T this[int index] => ref array[offset + index];
}

[IS4Code]

That would work too, but then you need a pre-existing storage location. If you wanted to validate the value or transform it in some way, this won't help you.

[jilles-sg]

I agree with the idea but not with the example. With the given MyClass, StorageSegment only needs to be used when the segment needs to be stored longer term (although this creates obscure aliasing), when the result needs to be stored in a local variable of an async method (and it is not possible or desirable to extract logic into a non-async method) or when using Linq on the data (incurring one or more virtual calls per byte). In none of these cases is it necessary to index the return value directly. In all other cases, Storage is a better choice than StorageSegment. This applies especially if the methods on Span<byte> or MemoryExtensions can be used or if the indexer is used multiple times on the return value (stored in a local variable).

[IS4Code]

I am notoriously bad at making convincing examples. 😄 I could not think of another type in the BCL that does this, so I picked one where it would have made sense if we didn't have Span already.

[IS4Code]

I took a stroll through the BCL and indeed the only type aside ArraySegment that does this is ParameterModifier which wraps bool[]. There might be other such patterns in other libraries though.

[jnm2]

This is exactly what is needed in order to simulate named indexes without a class allocation (#471 (reply in thread)):

If the wrapper struct (or even just the indexer's set accessor) is readonly, you're definitely not in need of a followup assignment back to the property:

var c = new C();

// Proposal: no error because the indexer's set accessor is readonly.
c.SimulatedNamedIndexer[42] = new object();

class C
{
    public WrapperStruct SimulatedNamedIndexer => new(this);

    public readonly struct WrapperStruct(C c)
    {
        public object this[int index]
        {
            // Indexer accesses private state or calls private methods in 'c'
            get => ...;
            set => ...;
        }
    }
}

[jnm2]

Similarly, this is blocked but it would not have to be blocked; the blocking could be done on a per-nested-member basis, allowing members marked as readonly:

// ❌ CS1918 Members of property 'C.ArraySegmentProp' of type 'ArraySegment<object>' cannot be assigned with an object
// initializer because it is of a value type
_ = new C { ArraySegmentProp = { [42] = new object() } };
//          ~~~~~~~~~~~~~~~~

class C
{
    public ArraySegment<object> ArraySegmentProp { get; set; }
}

Unsure of the usefulness of making this more granular, though.

[jnm2]

Now it seems this restriction has already been lifted once in regards to readonly value types, and that is if the value type is returned from a method.

This is true, the compiler does behave as you describe, but the v7 standard does not account for this. I opened dotnet/csharpstandard#1277 to fix it and potentially discover whether it is a compiler bug that the restriction was lifted for invocation expressions (e.g. methods), but not for other expressions (e.g. simple member access expressions, e.g. properties).

[jaredpar]

Now it seems this restriction has already been lifted once in regards to readonly value types, and that is if the value type is returned from a method
This is true ..

How is this true? The example above where the mutation is allowed is the Span<T> case. That is a case where the set is not called because the get returns a ref T.

[IS4Code]

@jaredpar I am not sure which example you are referring to. Mutation of a value returned from a method refers to this comment, where GetS().X = 2 is fine but becomes an error when readonly is removed.

[jaredpar]

@IS4Code i'm referring to the original post content. Assumed that since this thread was on the original post it was referring to content there.

[IS4Code]

@jaredpar I am sorry, I don't follow. I wrote that paragraph after the the observation that GetS().X = 2 works for a readonly setter, which was revealed to me by that comment. It was not referring to any of the examples in the post. I have slightly edited the paragraph and linked to @jnm2's thread to make it clearer.

[jaredpar]

I am sorry, I don't follow.

@jnm2 started a new comment thread here that had the comment "returned from a method". Given it was a new comment thread I assumed it was replying to content in the original discussion post. The only method call in the original post was storage.AsSpan() which was confusing me and lead to my comment.

You clarified that it was a comment in a different comment thread which clarifies but would've assumed this would've been a reply there or linked to it.

[jnm2]

I believe this discussion is a duplicate of #2068. At the time, it covered methods as well as properties, but the properties discussion remains.

[jnm2]

Proposal to lift this restriction: #9174