Proposal: init only methods

[acaly]

Since we have init-only properties, can we also have init-only methods? I imagine the syntax would be like:

class MyClass
{
    public int Value { get; init; }
    public init void EnableSomeFunction() { } //Maybe void here can be omitted?
}

var obj = new MyClass()
{
    Value = 1,
    EnableSomeFunction(),
};

This is to solve the "return this" methods, e.g., that constructs an instance of some service. There are plenty of such examples. One in the Avalonia UI:

public static AppBuilder BuildAvaloniaApp()
{
    return AppBuilder.Configure<App>()
        .UsePlatformDetect()
        .LogToDebug()
        .UseReactiveUI();
}

may be written instead as:

public static AppBuilder BuildAvaloniaApp()
{
    return new AppBuilder
    {
        Configure<App>(),
        UsePlatformDetect(),
        LogToDebug(),
        UseReactiveUI(),
    };
}

Advantages:

• Clear range of object initialization and improved readability.
• No need to abuse return value to chain multiple calls.
• Can be mixed together with property init.
• Ensure such methods can only be called during init (prevents misuse and helps understanding of the API).
• Works perfectly with extension methods (and extension properties after we have one).

[SirIntruder]

I like this in general.

Would it be possible to use return values of init methods inside init block? It would feel artificial if you can't, but if you can, it means we need init-block-local variables as well? You would want them for init methods with 'out' parameters as well.

[acaly]

I don't think it is a big problem if they can't have return values. Init methods and init properties are "expression-like", and they always starts with the name of a member of the type. If we allow local variables, these two would no longer be true. Another issue would be how to make sure user only put init properties and methods not something else as the initializer of these local variables. I feel we would have to allow many other statements if we allow that.

[HaloFour]

This was discussed at a language design meeting back in June:
https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-06-15.md#init-methods

TL;DR:

We're still very interested in the feature, but we need to determine how we can add it in a way that provides a path forward for our existing collections.

[acaly]

Thanks for the information. I can understand the difficulties with collections here.

[acaly]

But that discussion mainly addresses using init only Add to modify immutable collections, which is difficult because immutable collections are by design immutable even in init stage (different from initonly fields). If that's not easily achievable, what is the problem of creating a Builder with Adds followed by ToImmutable? In my opinion, this does not prevent adding init only methods for other purposes. Is the language design team still planning to work on solving the init Add of immutable collections?