constructor/initonly private methods inside of classes

[ctigrisht]

Hey!
I consistently come across an issue, that is long constructors for classes that need a lot of config, I end up having to make readonly fields mutable just to split the constructor logic into sane containers.

I'd like to have a new type of method that would allow mutating readonly values, as they could only be called by the constructor.
Here is an example below:

class SuperClass
{
    public SuperClass(ConfigStruct someHugeConfig){
        _performInitOnlyConfig(someHugeConfig);
    }

    private readonly SubConfigStruct _subConfig;

    initonly void _performInitOnlyConfig(ConfigStruct config) // it's private by default and cannot be called by members other than the constructor
    {
        _subConfig = config.GetSubConfig(); // assigns a readonly because it is part of the constructor
    }
}

[spydacarnage]

You can already split it out like this:

class SuperClass
{
    public SuperClass(ConfigStruct someHugeConfig){
        _subConfig = PerformInitOnlyConfig(someHugeConfig);
    }

    private readonly SubConfigStruct _subConfig;

    private SubConfigStruct PerformInitOnlyConfig(ConfigStruct config)
    {
        return config.GetSubConfig();
    }
}

[ctigrisht]

this is true, but sometimes you might want to assign multiple values in a single method, say you have 15 different ints, you don't want 15 init methods

[spydacarnage]

At that point you're just creating a big init method instead of a big constructor - I don't see the benefit of that.
And if you need to, for example, split that block of 15 variables into 5 methods, each setting 3 fields, tuple assignment is your friend.

(_field1, _field2, _field3) = PerformInit();

[martin-steinhoefer]

A type that has 15 independent fields (coming from 15 .ctor parameters) has a fundamental problem...
That one could be addressed by using arrays or other containers (fully or partially) or by creating custom types, holding all or some of those fields. Thereby breaking down the problem into manageable pieces. For some cases the tuple return approach (as proposed by @spydacarnage ) is also a good solution. Perhaps combining them would solve the read-only (immutability) problem for large creation state.

[huoyaoyuan]

#4238
#348
#1871
#1296
#8527

[TonyValenti]

What I will do is sometimes make my sub-constructor methods either take refs or have returns/outs that I immediately assign to the constructor properties. Not ideal but it works.