(Proposal) readonly methods and properties for initialization [CLR change]

[lachbaer]

readonly methods and properties for initialization

Continuation of Proposal: read-only setter (again) (dotnet/roslyn#13048)

Intent

The readonly modifier currently only allows to let the corresponding fields be set in the direct constructor body only.

This proposal extends the usage of readonly to be used in other places as well.

That should allow for more modular code where e.g. a constraint for a property is checked in its setter.

Behaviour and constraints

Methods and properties can also be decorated with the readonly keyword.

Methods

readonly methods can only be called by

• the constructor
• other readonly methods (thus indirectly belonging to the constructor)
  Obviously public and internal methods don't make sense.
• readonly properties - setter and maybe getter?

Properties

readonly properties can only be set

• in the constructor
• in readonly methods
• from other readonly properties - setter and maybe getter?
• in the object initialization part

Motivation

This would require a CLR change to hoist the meaning of readonly.

In essence, from the CLR point of view, readonly will allow to change readonly fields from every method that is also decorated as readonly.

The compiler ensures that the above mentioned constraints will be met. That will make sure that readonly fields can still only be initialized from the constructor or the directly following initialization part.

Syntax

Following bogus example shows the usage:

class Person
{
    private readonly string _name = null;
    private readonly double _complexCalculatedResult;

    public readonly string Name
    {
        get => _name;
        set => _name ?? "(none)";
    }

    private readonly void CalculateComplexResult()
    {
        FurtherCalculation(ref _complexCalculatedResult);
    }

    private readonly FurtherCalculation(ref double value)
    {
        value = 0;
    }

    public Person()
    {
        CalculateComplexResult()
    }

    // Usage:
    public static Person Create()
    {
        var p = new Person() { Name = "Humus" };
    }
}

Issues

Malicious emitters

Can malicious emitters produce MSIL that calls readonly methods or setters from other places than the constructor or initializer? The CLR would not recognize that as long as everything is decorated with readonly.
The CLR ensures that the caller also is readonly or the constructor. But for readonly properties only the compiler restricts its use to the initializer.

Parent of initializer call

The parent of the initializer calls to set_Xxx(value) is not readonly. The CLR must skip the readonly-verification for setters.

[john-cd]

See #318 - we discussed read only properties. We discussed at the end a new keyword / accessor, because 'read only' is a bit of a misnomer.

Note: Doing everything in the constructor is a code smell. Complex initialization is OK but lengthy computation would not - your design esp. read only methods encourage the latter. Think about the type of exceptions a developer would reasonably expect from a constructor call.

[HaloFour]

In essence, from the CLR point of view, readonly will allow to change readonly fields from every method that is also decorated as readonly.

In your example you demonstrate setting a readonly property in an object initializer. To the CLR there is no such thing as an object initializer or any form of initialization outside of what happens in the constructor. Object initializer syntax is purely syntax candy for setting properties directly of a fully instantiated instance. How do you propose that the CLR selectively enforce the readonly-ness of this method enough to satisfy the verifier without leaving gaping holes in the enforcement of the underlying initonly fields? You seem to suggest that this is the responsibility of the compiler and not the runtime, which is a position on which I would disagree.

Note: Doing everything in the constructor is a code smell.

C# has never required that all of this is done in the constructor. Only that the assignment of readonly fields is done in the constructor. The constructor is fully able to assign those fields from the result of a method, including passing those fields as ref or out parameters. In my opinion it's significantly better design to write said initializing methods completely independently anyway as then you can test them individually without having them be tied to a specific instance or it's initialization.

[DavidArno]

I'm really struggling to see the point of this proposal. Maybe I'm just stuck on the oxymoron of "readonly setters" and that it could just be that "readonly" is the wrong term to use.

[lachbaer]

@DavidArno
The proposal shall allow for one-time-written fields. But the fields must be either written from the constructor or one of its called methods (or deeper) or from the object initializer.

During the development process this would allow to outsource initialization logic to dedicated methods that e.g. need to set more than 1 field. Or the code can be moved to, and therefore being near to the corresponding property. The constructor can be kept nice and short.

When the calculation gets too complex, it shouldn't be done in the constructor anyhow. As the corresponding calculation may already be in a dedicated method, refactoring might be easier.

For "readonly" properties maybe the CLR can check whether the setter of a property is only called once and thus ensuring the safe use.

In the code, a readonly property can only be accessed from the object initializer. As the initializer is called after the construction, lengthy operations can be assigned there (and it looks good, too).

So the former readonly method that was called by the constructor can now be converted to or called by the setter (with a little modification). The CLR and language design toghether ensures that we are still in the initialization phase.

[Richiban]

I would support a proposal that's somewhat similar to this: readonly can be applied to methods and properties with the meaning being that this particular method / property doesn't mutate the underlying object. This would be enforced by a readonly being unable to call any methods / properties that are not also readonly and being unable to call setters at all. static members are implicitly readonly.

It sort of crosses over with the idea of a method being pure, but not exactly.

This also sort of crosses over with immutable classes, which I've seen before in the repo of issues but for some reason I'm struggling to find right now. Basically an immutable class would be a class where all the methods / properties are readonly / static.

@lachbaer I think this gives you a lot of the behaviour you want, but with a slightly less confusing use of the work readonly.

It would kind of be like Swift's mutating keyword, but the other way around.

[lachbaer]

Maybe, readonly is indeed the wrong term for this proposal and initonly would be more concise on what is intended.

I have already seen some lengthy constructors, that do several work but no 'costly' things. Those constructors are absolutely fine, though having many lines of code. This proposal could help to tidy this up a bit, especially when a single assignment would complicate things, because there are dependencies between different readonly fields.

Also things like { WasCompilerGenerated = true }, what currently cannot be readonly, but always actually falls in the initialization state, could be realized the readonly way.

[binki]

outsource initialization logic to dedicated methods that e.g. need to set more than 1 field.

Couldn’t you just make your readonly field’s type be struct which you could then pass to your method which accepts a ref or out?

This sort of thing seems confusing to me. In many cases you might just write a static method that performs the complicated computations and then passes the result to a new Constructor() call. If your only goal is to write fewer lines of code in the constructor, I think the existing features of the compiler enable you to do so. The proposed specialized support seems too confusing.

If you wanted this feature, instead of changing the CLR’s initonly enforcement, the C# compiler could just inline all readonly setters and automatically rewrite “readonly” methods to use out parameters and still actually perform the field set in the constructor. I don’t see why a CLR change would be necessary to add support for this syntax, but the syntax would require the compiler to do a lot of transformation to properly respect initonly. And all of these readonly methods and setters would only ever have one callsite—the constructor. So the primary use of methods—reusability of code—would be lost. You might as well just use {} blocks or #region/#endregion in your constructor to organize code into topics.

[Joe4evr]

During the development process this would allow to outsource initialization logic to dedicated methods

Okay, yes....

that e.g. need to set more than 1 field.

Wait what? Classically, doesn't make a lot of sense to set more than one field at a time, but I can see if you have two properties being related but one can't be derived from the other (for whatever reason), but it would be entirely possible to do so now with Tuples without needing any sort of new syntax.

public class Foo
{
    public int One { get; }
    public int Two { get; }
    public string Three { get; }

    public Foo(int one, int two, string three)
    {
        // don't think you can deconstruct straight into properties,
        // so using a temp to hold the deconstruction
        var (i, j) = ValidateCombination(one, two);
        // constructor is still in charge of the actual assignment
        One = i;
        Two = j;
        // and a single validation can be assigned directly into the property
        Three = ValidateThree(three);
    }

    private static (int i, int j) ValidateCombination(int one, int two)
    {
        // .....
        return (one, two);
    }

    private static string ValidateThree(string three)
    {
        // .....
        return three;
    }
}

[Opiumtm]

@lachbaer

The compiler ensures that the above mentioned constraints will be met.

How about IL emit at runtime? How about IL assembler? Compiler for another language?

Type safety at runtime-level would be compromised if safety would be "ensured" by C# compiler only.

[aluanhaddad]

@lachbaer

The proposal shall allow for one-time-written fields. But the fields must be either written from the constructor or one of its called methods (or deeper) or from the object initializer.

I actually really like such an idea. Maybe it is bad design on my part, but I sometimes have properties that don't have an initial value, are not lazy, and are meant to be written once often externally.

For example

interface IModifiable<TModifiable, TModifier> where TModifier: IModifier<TModifiable>
{
    void ModifyWith(TModifier modifier)
    TModifier Modifier { get; }
}

Granted, it would be better to use an immutable type and simply return a new object as in

interface IModifiable<TModifiable, TModifier> where TModifier: IModifier<TModifiable>
{
    TModifiable ModifyWith(TModifier modifier)
    TModifier Modifier { get; }
}

but this is not always desirable.

[AustinBryan]

initonly is a much better word, or ctoronly. readonly makes me think of function pointers. I get the idea being that they can assign readonly fields and you don't want to make a new keyword, but it's a bit misleading.

Can't you use local functions though and use this and base calls which would then use those local functions?

[bootzin]

Well, since other issues opened regarding this matter have been closed, and there's been 3 years since last activity here, I'm curious as to whether there is any plans on doing something similar

[HaloFour]

The team had expressed interest in exploring init methods during a design meeting in June of this year. I believe they envision them being used by initializer expressions such as collection initializers and I do think that they'd target a feature that would ideally make initializing immutable collections possible, but I think that the use case of calling private helper methods from within the constructor that could assign read only fields would be included in that conversation.

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-06-15.md#init-methods

[juwens]

If you use Rx you have this problem often, because constructors get quite long.
I would appreciate this feature a LOT.

[rofenix2]

I am looking for something like this, it makes the language richer and more expressive. Also it works well for source code generators that generate constructors but you cant put custom logic on it and you need to put it in a Validation or Initialize method (nowdays you loose wirte access to readonly fields).

[crwsolutions]

I have created such a generator. I would be happy with just an attribute. Something like [ConstructorInlining] (above a partial method, which is called from the constructor). That would do something similar as the AggressiveInlining Flag and would allow you to set readonly fields.