Required Properties Inheritance Fine-Grained Control

[fitdev]

I am using latest VS 2022 17.3 Preview 2. According to Language Feature Status the bits with required members support are already in VS 17.3 P2, and I can use the new required keyword just fine.

However, I was wondering if it's by design or a bug if I do not set the required member explicitly in the derived class instantiation (because it is already set explicitly within the derived class's constructor):

public class Base {
    
    public required int property A { get; set; } = 0;
    
}

public class Child : Base {

    public Child() {
      A = 12; // <-- NOTE: Set explicitly here, should satisfy the required requirement
    }

    public int property B { get; set; } = 0;

}

public class UserCode {
  
  public void Main() {
    var child = new Child(); // <-- CS9035: Required member 'Base.A' must be set in the object initializer or attribute constructor.
  }

}

So, why does it complain with CS9035? Required property A is set explicitly in the Child's constructor, why the need for me to also set it in my user code when I instantiate the child class?

UPDATE:

Answer was provided by @ufcpp to use [System.Diagnostics.CodeAnalysis.SetsRequiredMembers] attribute on the constructor. Which works great, however this raises another issue...

As per docs from SetsRequiredMembersAttribute and from the design:

Specifies that this constructor sets all required members for the current type, and callers do not need to set any required members themselves.

Does it therefore mean that should the above scenario be made a bit more complex:

public class Base {
    
    public required int property A { get; set; } = 0;
    public required int property A2 { get; set; } = 0;
    
}

public class Child : Base {

    [SetsRequiredMembers]
    public Child() {
      A = 12;
     //NOTE: Required A2 is NOT set here
    }

    public int property B { get; set; } = 0;

}

public class UserCode {
  
  public void Main() {
    var child = new Child(); // <-- No error now even though Child's constructor only set required property A, and NOT A2, which is left unset.
  }

}

... that it is not possible currently to selectively set required members? That is: it seems that currently there is only "all" or "none" mechanism to specify which required members have been set by a constructor.

Would it not have been better to have performed simple recursive analysis, progressively looking at constructor chain to determine which required members have been definitely assigned, and which have not?

Such more fine-grained control would:

• Remove the necessity to use SetsRequiredMembers attribute
• Provide more granular control over which members should be set by the user code in more complex class hierarchies

Any reasons why this approach have not been taken, and will it be looked at in the future?

[ufcpp]

    [System.Diagnostics.CodeAnalysis.SetsRequiredMembers]
    public Child()
    {
        A = 12;
    }

[fitdev]

Thanks for letting me know about this attribute.

[333fred]

That is: it seems that currently there is only "all" or "none" mechanism to specify which required members have been set by a constructor.

That is correct. An earlier version allowed for more complex control, but we decided to simplify for now.

Would it not have been better to have performed simple recursive analysis, progressively looking at constructor chain to determine which required members have been definitely assigned, and which have not?

No, this has never and will never be on the table. Control flow analysis is too easily fooled or confused for use in determining the public api of anything. For example, if you have multiple constructors and refactor a helper method for setting common things between those constructors, the analysis now misses whatever was set in that helper.

[fitdev]

I see. It makes sense. So, are there any plans to revisit this and somehow allow for a more fine-grained control?

[333fred]

So, are there any plans to revisit this and somehow allow for a more fine-grained control?

Potentially. We think the existing support will hit most of the use cases people need. But we are open to exploring enhancements in the future, provided we hear a need for it.

[fitdev]

I hope that you do. Because in the slightly more complex scenario I outlined above it seems that the current solution is half-baked so to speak. Meaning that I, as a library author, for example, might want to have strong guarantees that all required properties would be explicitly set one way (by the user with initializers) or another (by intermediate constructors).

Also, I was wondering regarding your comment

...Control flow analysis is too easily fooled or confused for use in determining the public api of anything....

... how did it work for structs? I mean there is a requirement for definite field assignments in their constructors. Why can't similar logic be used for required properties?

[333fred]

... how did it work for structs? I mean there is a requirement for definite field assignments in their constructors. Why can't similar logic be used for required properties?

Structs don't expose this information in any way, so it's not a public contract.