Public API design for readonly properties and events in C#

[RikkiGibson]

There's a bit of public API that should be added to symbols for the readonly members feature.

So far the following API has been added to MethodSymbol (handwaving a bit):

/// <summary>
/// Indicates whether the method is declared readonly, i.e.
/// whether 'this' is readonly in the scope of the method.
/// See also <see cref="IsEffectivelyReadOnly"/>
/// </summary>
internal abstract bool IsDeclaredReadOnly { get; }

/// <summary>
/// Indicates whether the method is effectively readonly,
/// by either the method or the containing type being marked readonly.
/// </summary>
internal bool IsEffectivelyReadOnly => ...;

It's also possible for properties or property accessors to have readonly modifiers.

public readonly int Prop1
{
    // both accessors are 'readonly'
    get => this._store["Prop1"];
    set { this._store["Prop1"] = value; }
}
public int Prop2
{
    readonly get => this._prop2;
    set { this._prop2 = value; }
}

If users of the compiler APIs want to know if a property was declared readonly, or just its accessor, it could be necessary to add new methods to IPropertySymbol. The trouble is that ReadOnly properties already have a meaning in VB and in the existing property APIs: it means there is no set accessor.

This means that just copying the APIs from MethodSymbol to PropertySymbol is likely to cause confusion. We need a path forward where users can determine these facts about C# properties without causing confusion about VB properties or confusion with the existing API.

[RikkiGibson]

We've decided that properties in metadata will never have the IsReadOnlyAttribute--only methods will (including accessors). Therefore it might be reasonable to let only methods have new API related to the readonly members feature.

[RikkiGibson]

It seems reasonable that IEventSymbol should have an bool IsReadOnly property. But it's hard to be consistent across the different kinds of members that support readonly. @jasonmalinowski