Required members: Please remove CS9032 (or at least make it a warning).

[TonyValenti]

@333fred -
I just started playing with required members and I'm having a less-than-optimal experience due to CS9032.

I believe that CS9032 should be removed completely.

Remove CS9032 because it is not DI-Friendly

Consider this use-case:
I use AutoFac for dependency injection.
I have lots of classes that look like this:

    public class MyClass
    {
        private Class1 Dependency1 { get; }
        private Class2 Dependency2 { get; }
        private Class3 Dependency3 { get; }

        public MyClass(
            Class1 Dependency1,
            Class2 Dependency2,
            Class3 Dependency3
            )
        {
            this.Dependency1 = Dependency1;
            this.Dependency2 = Dependency2;
            this.Dependency3 = Dependency3;

        }

    }

By leveraging required and new AutoFac settings, I want to refactor my code to look like this:

    public class MyClass
    {
        private required Class1 Dependency1 { get; init; }
        private required Class2 Dependency2 { get; init; }
        private required Class3 Dependency3 { get; init; }
    }

However, today, I can't do that because CS9032 prevents it.

Remove CS9032 because it prevents expressing intent

Consider this code:

    public class Foo2
    {
        private required int Age { get; }

        [SetsRequiredMembers]
        public Foo2(int age)
        {
            this.Age = age;
        }

    }

CS9032 prevents me from specifying an internal requirement that any constructors I create should explicitly set Age.

[CyrusNajmabadi]

prevents me from specifying an internal requirement that any constructors I create should explicitly set Age.

You can write an analyzer here that you can use to apply your own domain requirements that all your constructors assign this.

[chrisoverzero]

Do you mean “CS9032”?

[TonyValenti]

Oops! Yes. I just updated the discussion.

[qrli]

specifying an internal requirement that any constructors I create should explicitly set Age.

I see this is a common misuse (or unintended expectation) of this required property feature. You are expecting the compiler to enforce assignment in the constructor, but the compiler does not really enforce that except simple cases, because it is too expensive to analyze all code paths. The [SetsRequiredMembers] is to help compiler by telling compiler that you swear on it, rather than asking compiler to enforce it in the constructor.

[333fred]

The code you are trying to write is objectively not different if you remove the required modifier and SetsRequiredMembers attribute, except that it compiles.

[HaloFour]

@TonyValenti

This is code that I'd like to write that the above error prevents

The use of the required modifier in that snippet doesn't make sense. The keyword is intended to specify that the member must be assigned within an initializer, but it's not possible to assign that member within an initializer. That member needs at least an init accessor.

[TonyValenti]

Here is another example of the error getting in the way:

    public class Foo4
    {
        internal required int Age { get; set; }
        internal Foo4() { }
    }

[HaloFour]

I can see that it would make more sense to enforce that the required members are at least as accessible as the constructors of that type rather than the type itself.

[333fred]

We debated that, but this isn't a sealed type.

public class Foo5 : Foo4 {} // Oops

In general, this is just not a scenario that required members is currently targeted to addressing.

[RikkiGibson]

is a pattern like this suitable for your use case?

public class MyClass
{
    public required Class1 Dependency1 { private get; init; }
    public required Class2 Dependency2 { private get; init; }
    public required Class3 Dependency3 { private get; init; }
}

[TahirAhmadov]

In my work, I usually do protected get, so that child classes don't need to re-specify the same dependency once more.