Should CS9032 validate constructor visibility instead of type visibility for sealed classes?

[bbascarevic]

I believe that the visibility validation for property setters/initializers (CS9032) could be overly-restrictive in its current form. Consider the following code:

public sealed class Foo
{
    // CS9032!
    public required object Baz { get; private set; }
    
    private Foo() { }

    ...
}

public sealed class Bar
{
    // CS9032!
    public required object Bar { get; internal set; }
    
    internal Foo() { }

    ...
}

The above code yields CS9032 errors during compilation because both setters are less visible than the enclosing type. I assume the reasoning is to prevent the definition of uninitializable (and thereby effectively uninstantiable) classes.

Whether or not a class is instantiable is determined by its constructors and their visibility at the call site. For non-sealed classes, a derived class can have more visible constructors than the base class' constructors. This can lead to a situation where a class is uninitializable, because a required property writer is not accessible at the call site while the constructor is.

However, for sealed classes there's no way to "upgrade" the visibility of constructors. So for sealed classes, should CS9032 verify that property writers of required properties are "at least as accessible as the most accessible constructor", instead of "at least as accessible as the enclosing class"?

[333fred]

See https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-01-05.md#required-properties-accessibilities, where discussed and disallowed the scenario for now. We could conceivably relax it, but there are some very thorny issues around inheritance to work out. For example, what if a derived type added a public constructor? What does that do to the base required internal property?

[bbascarevic]

@333fred Thank you for the reply.

For example, what if a derived type added a public constructor? What does that do to the base required internal property?

I thought I addressed that by restricting the proposed behavior to sealed classes only (it says so in the title and the body).

The problem is that there's currently no way of having privately-settable properties that are also required. The biggest issue are non-nullable properties, there's no way to enforce their non-nullability if their set/init is non-public:

public sealed class Foo
{
    public object Baz { get; private init; }
    
    //Error CS8618 : Non-nullable property 'Baz' must contain a non-null value when exiting constructor.
    private Foo() { }

    ...
}

required was supposed to take care of that, but it can't because of CS9032. The only other option is a parameterized constructor, but that defeats the purpose of the required keyword altogether.

I understand and agree with the reasoning for non-sealed classes though.

[DavidArno]

I'd prefer to see the language support required properties in sealed classes having to have the same visibility as the most visible constructor. But your approach of relaxing the rules around CS9032 for sealed classes would be a good alternative. Obviously, the language has to cope with the "thorny issues" that inheritance creates, but it would be good to see the "happy path" of sealed classes being given the same amount of love at times.

[devsko]

This is especially useful for async factories with private ctor.