[Proposal] Allow local functions in constructor to modify readonly fields

[lazyloader]

It has been pointed out by a few people on here already that it would be nice to have methods that can set readonly fields. This seems to defeat the point, so they often have some limitations:

• Can't be called outside the constructor
• Can't be public
• etc.

However, those are already characteristics of local functions, so instead of allowing:

private readonly int X;

public Foo()
{
    InitA();
    InitB();
}

private constructOnly void InitA() { ... }    // pointlessly in full class scope where it can't be used
private constructOnly void InitB() => X = 1;

We should allow this:

private readonly int X;

public Foo()
{
    InitA();
    InitB();

    void InitA() { ... } 
    void InitB() => X = 1;    // Currently doesn't work
}

This condenses the information and expresses the fact that nothing can use InitA or InitB except for the constructor. It also takes up less lines and characters. I was surprised that this doesn't work, seeing as the local function is in the constructor, visually speaking, though I know it is compiled outside of it, however, I think it's intuitive to think it would work in this way.

[svick]

What would happen if you attempted to expose the local function outside of the constructor? E.g.:

private readonly int X;
private Action action;

public Foo()
{
    action = InitB;
    void InitB() => X = 1;    // Currently doesn't work
}

[theunrepentantgeek]

Conceptually, I quite like this - but I wonder how this would actually be implemented, given that local functions are (I believe) actually implemented as private methods with unprintable names.

[jnm2]

At that point, why not inline the local functions?

One of the motivating examples was sharing initialization logic between constructors, too.

[popcatalin81]

You actually can initialize a read-only field in a function if you pass it by ref:

class Foo
{
	private readonly int X;

	public Foo()
	{
		InitB(ref X); // works
	}
	
	private void InitB(ref int X) => X = 1;
}

So I guess this feature could be implemented as syntactic sugar withouth CLR changes. But I doubt the syntactic sugar is worth the cost here ...

[HaloFour]

@popcatalin81

A problem occurs if that constructor also happens to contain a lambda which encloses over the local state. In that case the parameters/fields are lifted into a display class along with the bodies of both the lambda and the local function. It's the kind of caveat that probably makes it not worth attempting to spec out or implement.

[lazyloader]

@theunrepentantgeek That's exactly my issue as well, C# does move them outside and changes the name.

public void Outer() 
{
    void Inner(){ }
}

Compiles into:

public void Outer() { }

[CompilerGenerated]
internal static void <Outer>g__Inner|0_0() { }

So the name keeps track of the method top-most parent function, so if I defined a method inside of Inner, it still says <Outer> at the top, but instead of 0_0, it says, 0_1.

If it's the constructor, however, the being of the local function name isn't <Foo> it's <.ctor>, so I imagine they can use that, doing something like allowing local functions set readonly fields if their name starts with <.ctor>.

[lazyloader]

@jnm2 Well, you wouldn't inline because if the constructor is very long, you might want to condense it into functions, as is the good practice and improves readiblity, even if you only use them once.

However, in constructors, that then means not being able to assign readonly fields, so you're forced to deal with less readible code. Also, you might want to use the same local function multiple times in the constructor.

Yes this doesn't solve the problem with sharing logic between constructors but I think it should be a feature regardless because the absence of it is counter intuitive.

[lazyloader]

@popcatalin81 What cost are you talking about? Also, see my reply to theunrepentantgeek, where I mention that all local and nested local functions, inside the constructor, and only them, start with <.ctor> in their name, and nothing else can start with that, therefore I think they can just check to see if the function starts with <.ctor> and if it does then it can change the field, unless there is something about readonly fields going on that would prevent that from happening.

[lazyloader]

@svick Good point. I guess a few things could happen:

1. Compile error, this can't be done.

2. X is treated as a local copy and the real, readonly X isn't changed

3. action can change the value of X therefore any method can, basically making X not so readonly as it used to be.

4. is my least favorite option for basically making it no longer readonly, and 1. might be too much brute force, but 2. could have performance issues making the copy.

[HaloFour]

@lazyloader

unless there is something about readonly fields going on that would prevent that from happening.

Any writes to an initonly field outside of the constructor produces an unverifiable assembly.

[popcatalin81]

unless there is something about readonly fields going on that would prevent that from happening.

@lazyloader The CLR and bytecode verification process prevents modifications to readonly fields.

See ECMA 335 II.16.1.2 Field contract attributes

initonly marks fields which are constant after they are initialized. These fields shall only be mutated
inside a constructor. If the field is a static field, then it shall be mutated only inside the type initializer
of the type in which it was declared. If it is an instance field, then it shall be mutated only in one of the
instance constructors of the type in which it was defined. It shall not be mutated in any other method or
in any other constructor, including constructors of derived classes.

[alrz]

it would be nice to have methods that can set readonly fields.

Rethink your constructors? A similar limitation is discussed here: #419. Bottom line: constructors should do the least amount of work, that is, member-wise initialization (and perhaps validation). Whenever you find yourself doing more, you should consider decoupling the requirements using some other mechanisms (like a factory method, etc).

[scalablecory]

I think this would need some sort of "ref delegate" or at the very least a "ref local method" to prevent it from escaping scope. Probably also a CLR change to allow writing to read-only fields from outside of a constructor.