LDM Notes for October 17th, 2022

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-10-17.md

Agenda

• Primary Constructors
• Permit variable declarations under disjunctive patterns

[jnm2]

init { } makes me think of final validators (which would run as the last part of all the init things) and it makes me wonder how they'd look alongside each other.

[qrli]

ClassName { } could be too verbose, especially when the class name is long, which defeats the purpose of primary constructor.
If init { } is to be used for final initializer, why not use new { } for primary constructor body.

[Joe4evr]

@MadsTorgersen Is there a proper discussion thread for Final initializers yet?

[HaloFour]

With autocomplete ClassName { } would require probably the same number of keystrokes as new { } or init { }. It's been stated that if C# were to be redesigned that the constructor syntax (if constructors were to still exist) might be reconsidered, but I think it's better to remain consistent with the language we have today.

Java uses ClassName { } for the constructor body with records:

public record Person(String name) {

    Person {
        Objects.requireNotNull(name, "name is null");
    }
}

[qrli]

Putting record aside and talking about primary constructor only, compare

public class Person(String name) {
    Person {
        Objects.requireNotNull(name, "name is null");
    }
}

to

public class Person {
    Person(String name) {
        Objects.requireNotNull(name, "name is null");
    }
}

Why bother?
And I'd argue primary constructor body is not the same thing as constructor.

[HaloFour]

Why bother?

Scope. You can't access name outside of the constructor body in the second example. My opinion is that this will be useful primarily for components that use dependency injection so that you can skip the boilerplate of field definitions and assignments for those dependencies.

[orthoxerox]

The biggest pain point for record constructors that I would love to see tackled by primary constructors is the need to switch to a regular constructor as soon as you want one of the following:

• validation (the biggest issue). !! would've solved like 80% of the cases, but not all of them
• different types on properties. params Foo[] to IReadOnlyList<Foo> is, again, 80% of the cases