Proposal: Allow partial method implementations to assign readonly fields

[daiplusplus]

Problem:

By-design readonly fields can only be assigned in their containing type's constructor. This becomes an issue when a partial class's constructor is outside of the programmer's control (e.g. a T4-generated or Designer-generated constructor). A good example is an MVVM ViewModel with readonly RelayCommand properties:

CalculatorViewModel.generated.cs:

// T4-generated ViewModel from a succinct viewmodel prototype declaration or reverse-engineered from a XAML file:

public partial class CalculatorViewModel : BaseViewModel
{
    public CalculatorViewModel()
    {
        this.AddCommand = new RelayCommand( this.Add );
        this.SubtractCommand = new RelayCommand( this.Subtract );
    }

    partial void Add();
    partial void Subtract();

    public RelayCommand AddCommand { get; }
    public RelayCommand SubtractCommand { get; }
    // etc
}

CalculatorViewModel.cs:

// Programmer-controlled file:

public partial class CalculatorViewModel
{
    partial void Add() { this.Result = this.Result + this.CurrentInput; }
    partial void Subtract() { this.Result = this.Result - this.CurrentInput; }
}

With this arrangement the programmer is unable to add new readonly fields to CalculatorViewModel because the single constructor is in the generated file and any changes will be overwritten during the next build.

Proposed solution

As partial methods are a design-time syntactic concern the readonly correctness checks can still be maintained while allowing assignment to readonly members.

The constructor would still be in the generated.cs file, except the generated constructor would call a new partial method (just like WinForms InitializeComponent) except that readonly assignment is now allowed provided the partial method is only called from a constructor:

CalculatorViewModel.generated.cs:

// T4-generated ViewModel from a succinct viewmodel prototyping system or reverse-engineered from a XAML file:

public partial class CalculatorViewModel : BaseViewModel
{
    public CalculatorViewModel()
    {
        this.AddCommand = new RelayCommand( this.Add );
        this.SubtractCommand = new RelayCommand( this.Subtract );

        this.UserConstructor();
    }

    partial void UserConstructor();

    partial void Add();
    partial void Subtract();

    public RelayCommand AddCommand { get; }
    public RelayCommand SubtractCommand { get; }
    // etc
}

CalculatorViewModel.cs:

// Programmer-controlled file:

public partial class CalculatorViewModel
{
    private readonly Boolean giveIncorrectAnswers;

    partial void UserConstructor()
    {
        this.giveIncorrectAnswers = new Random().Next(0, 2) == 1;
    }

    partial void Add()
    {
        if( this.giveIncorrectAnswers ) this.Subtract();
        else this.Result = this.Result + this.CurrentInput;
    }
    partial void Subtract() { this.Result = this.Result - this.CurrentInput; }
}

The compiler would internally tag any partial void methods as alters-readonly as it encounters them and then prohibit calling them from outside a constructor, and the compiler would then use this tag to prove that inlining the partial void implementation is correct. I understand the semantics of partial void means that inlining does not result in any change in program behaviour.

CalculatorViewModel.cs:

    partial void Add()
    {
        this.UserConstructor(); // <-- would raise a compile-time error because `UserConstructor` mutates readonly fields
    }

[HaloFour]

This would require that the compiler inline the body of the partial method into the constructor.

[daiplusplus]

This would require that the compiler inline the body of the partial method into the constructor.

Yes, I believe that would be correct behaviour in this case if the CLR enforced readonly correctness at runtime.

[DavidArno]

Loosely related: #348