FYI. @jaredpar

This would allow better use of in with things like System.Numerics.Matrix4x4, which is big enough that it is sometimes better to pass around using in (due to size -- 64 bytes), but which can't be marked readonly due to a design-decision to make the fields public and writeable (even if the majority of methods exposed don't modify state).

It isn't mentioned above, but it may be worth discussing if a readonly method should only be able to call other readonly methods...

Today, with readonly fields of non-readonly structs, C# will make a copy of the struct. For example, the following prints 0 twice, rather than 0, 1: https://sharplab.io/#v2:C4LglgNgNAJiDUAfAAgZgAQCcCmBDGA9gHYQCe6AzsJgK4DGw6AGgLABQA3u+j+mlnkIlyATXSkA3O269+yACzoAytmAiAFAEoZPLm14HxAOhVr1ARiMAGAGaap+3gF92Ltu35VaDdCPZ6DfhsIAlxGADdcCBpsBwMdPgwFZVUNYNCIqJjtR10Eg2AACzAKI0jo7ABedHKYuOdXaTY5cwA2PgAmPnMAdn8Elvbk5HMADnURqwBtAF10XEwAcwocgwDDHiZ0AA90aqJsAHdmLXqNkaMRgE51baNSMqzse3zeV5470w0X3MML69u90eFR+BjcTiAA=

Conceptually I like it, a lot. I do have some issues with it, though.

First, such an attribute already exists, System.Diagnostics.Contracts.PureAttribute, which is supposed to mean the same thing but isn't enforced by the compiler. Adding another attribute to support this feature would be noise.

There's also the chicken&egg problem in that the BCL and ecosystem would have to be updated for this to be particularly useful otherwise these methods are stuck not being able to call out to other methods.

Next there is the issue of what defines "pure". In this case we could keep it to situations where the compiler can safely not make defensive copies, but philosophically it extends beyond that. Perhaps readonly as a keyword would help to divorce this concept from "purity", although they do seem to cover the same bases.

Lastly, readonly is already a valid modifier on the return value of a method. The position is different, but that might still lead to confusion, especially since most of the time modifier keywords can be placed in any order.

Adding another attribute to support this feature would be noise.

We would have to add another attribute, however. The existing attribute has no enforcement, as you indicated, and as such would be a breaking change to begin enforcing it now.

There's also the chicken&egg problem in that the BCL and ecosystem would have to be updated for this to be particularly useful otherwise these methods are stuck not being able to call out to other methods.

This is only applicable if we restrict the ability to only call other readonly methods (#1710 (comment))

There could be a difference between a readonly and a pure method. A pure method, by definition, cannot modify any state. A readonly method (in order to satisfy the in constraint and elide the copy) must only guarantee that it does not modify instance state (it could be allowed to do things like call Console.WriteLine, which would allow copy elision, but would not be functionally pure).

It can be summed as All pure methods are readonly, but not all readonly methods are pure.

Depending on what LDM thinls, it could go one way or the other. If we did differentiate, then pure functions would be a natural stepping stone from readonly (and constexpr would again be a natural stepping stone from pure).

Lastly, readonly is already a valid modifier on the return value of a method. The position is different, but that might still lead to confusion, especially since most of the time modifier keywords can be placed in any order.

Right, I called this out in the notes section.

I'm 85% sure this has all been thrashed out before - but I'm unable to find it with a quick search.

One of the real problems is that different developers will have different expectations. Some will expect this to mean that literally no changes are made, none at all, by the method. Others will expect this to mean that no externally visible changes are made.

The former is rigorous and useful from both theoretical and practical perspectives. The later permits result caching (which can be really useful for performance) and other internal changes.

Many of the original decisions in the design of C# were driven by a desire to avoid versioning issues as code evolves - this is, for example, one of the reasons why checked exceptions were not included.

What restrictions on the evolution of my code do I have if I have a property declared like this:

    public string AccessKey
    {
        readonly get { ... }
    }

My own opinion is that I don't think that adding internal caching should have any effect on the external interface; if I need to remove the readonly modifier to add caching, that could have very large cascading effects - and if it's a published API (e.g. via NuGet) then I might not be able to do it at all without breaking people.

That said, I know smart developers who disagree with me fervently on this topic ... 😁

Another scenario to consider ... if you have something with a pure API, and then you modify it to generate audit logs (for legal compliance reasons), should you need to change the declaration of the API?

@theunrepentantgeek, right. pure has a number of additional considerations. However, the original post just covers readonly methods, which would not have many of these considerations.

At its root, a readonly method (as proposed) would only guarantee that instance state isn't modified (which would imply calls to System.Console.WriteLine, while not pure, would be allowe).

Added a root note, at the top of the post, clarifying that readonly method != pure method

@tannergooding

Provide a way to specify that methods do not modify state.

Consider instead

Provide a way to specify individual methods on a struct do not modify state in the same way that readonly struct specifies no instance method modifies state.

@tannergooding

Using the readonly keyword is useful, since it is an existing keyword. However, it may get confusing to read if you have something like public readonly ref readonly float GetRefToX() (const T* const anyone 😄)

It's not just that it's confusing, it's also ambiguous with other potential features. The compiler specifically chose to use ref readonly instead of readonly ref for locals / returns because we wanted to allow for the future addition of readonly ref readonly local variables once readonly locals are introduced.

The individual variations are the following for locals in that context:

• ref: a reference which can be assigned to and reassigned to a new location
• ref readonly: a reference which cannot be assigned to but can be reassigned to a new location
• readonly ref : a reference which can be assigned to but cannot be reassigned to a new location
• readonly ref readonly: a reference which cannot be assigned to or reassigned to a new location

I wouldn't want to use readonly as proposed here because it would create a bit of confusion between the two cases: specifying a readonly method and readonly locals.

This feature was discussed in LDM when we discussed the readonly struct feature. At the time the syntax we were considering is the following:

struct S1 { 
  int i; 
  public void M() readonly { ... } 
}

That is putting the readonly modifier after the method signature. This is unambiguous and fairly easy to read. This is how we actually implemented permissions in Midori and it works out fairly well. Admittedly it does take some getting used to though for anyone who doesn't have a C++ background.

After the method seems reasonable to me. Will update the proposal later tonight.

@jaredpar, where would you envision the keyword for properties?

Is it before or after the get keyword (changed it to after in the OP):

public float LengthSquared
{
    get readonly
    {
        return (x * x) +
               (y * y);
    }
}

// vs

public float LengthSquared
{
    readonly get
    {
        return (x * x) +
               (y * y);
    }
}

I would imagine that specifying it individually on the get/set is preferred here, since set (in most normal API designs) wouldn't qualify for the attribute 😄