Enhanced Support for Required Init-Only Properties with Object Initializers

[nyan-cat]

Good day!

I have a request to improve how required init-only properties work with object initializers. The current SetsRequiredMembers attribute helps, but it disables compile-time checks for required properties.

Feature Request
Enhance C# to ensure all required init-only properties are initialized when using object initializers, without needing SetsRequiredMembers.

Example

public record CustomerData
{
    public required string FirstName { get; init; }
    public required string LastName { get; init; }
    public required string Email { get; init; }
}

public record Customer : CustomerData
{
    public required Guid Id { get; init; } // This is required

    [SetsRequiredMembers]
    public Customer(CustomerData data)
        : base(data) // Won't compile without SetsRequiredMembers
    {
        // I should init Id here, I know, but I'd rather use object initializer instead
    }
}

public Customer CreateCustomer(CustomerData data)
{
    return new Customer(data)
    {
        Id = Guid.NewGuid() // Can be commented out because of SetsRequiredMembers, no matter of required
    };
}

With SetsRequiredMembers, Id isn't checked as required. I want the compiler to enforce that all required properties are set. In fact, we just don't need SetsRequiredMembers, we should be able to delegate requireds to the caller of the record constructor.

Thanks for considering this request!

[FaustVX]

IIRC, SetsRequiredMembers means "trust me, I know what I am doing" to the compiler.

[nyan-cat]

Yep, and currently it's the only way. The point is - we need to be able to initialize some properties in a constructor, the rest of them - with an object initializer, and only after do a compile check if all required priperties are initialized.

[colejohnson66]

I definitely would like to see an augmentation of [SetsRequiredMembers] to allow saying which properties. Basically, instead of saying it sets all of them, it only sets some of them.

So, an array parameter could be provided that calls out the subset:

[SetsRequiredMembers("FirstName")] // `LastName` is not set

[RikkiGibson]

The language design team looked in some detail about how we could do "piecemeal required members", enabling different constructors to require different members to be set in the object initializer, etc., and ultimately rejected it in favor of the current simplified design.

I personally don't anticipate that this kind of support will be added at the language level. But, someone who feels passionate about this feature area, could consider writing an analyzer which "enriches" the behavior here, introducing both enforcement that required members are set when SetRequiredMembers is used, as well as allowing "granular opt-in" for which members are set by which constructors.

[333fred]

One thing that may be useful to spell out is explicit scenarios where it would be helpful. The "what if I want" type of scenario is useful for some amount of brainstorming, but to overcome the -100 points that any feature starts with, more concrete scenarios are useful.

[nyan-cat]

I think you've gone a little off topic. Let me focus on a feature I want:

When a class (or a record) has required properties and user-defined constructor, compile-time checks on required properties are done at a constructor definition level. Because of that, when both constructor and object initializer are used, it works in the following order:

1. Constructor invocation
2. Required members initialization checks
3. Object initializer

Yes, it's not really this way since required members are being checked on a constructor definition level, not invocation site. So my proposal is to move required members checks from a constructor defintion to a constructor invocation, and do those compile-time checks after both constructor invocation and object initializer did their duty, so it could work in this order:

1. Constructor invocation
2. Object initializer
3. Required members initialization checks

We ain't introducing new features neither make the language more complex. We have backward compatibility. We haven't lost any compile-time guarantees we had before, and we can initalize objects in a simper way.

[333fred]

The constructor body possibly doesn't exist at compile time. For example, reference assemblies usually do not include the bodies, they just throw null, in order to keep the assembly small. We also have no intention of inferring part of the public api contract of a type from a method body, as that is brittle to unintentional changes silently changing the meaning of them.

[HaloFour]

I agree that it would be nice if SetsRequiredMembers could be more granular and indicate which of the required properties have been set vs. all or none.

However, beyond that, I agree that the declaration as to which properties are set should be explicit and part of the contract of that constructor. You can make the argument that the compiler should know which members are set, but that assumes that the class in question lives in the same assembly. Taken as a reference the constructor body is entirely opaque, even if it's not a reference assembly. But more than that, even if you have the code it's not as simple to infer which of those properties have been set as those properties don't have to be auto-properties, and how would you expect the compiler to understand that whatever machinery backs that property has effectively been set? You really can't. An analyzer could take a stab at it, but it could never be completely accurate. So attempting to automatically derive the attribute from the constructor body doesn't sound like a practical solution, at best a "fixup" option provided by an analyzer knowing that said approach would be limited in what it can infer.