Add warnings for initializers that reference other fields or properties in same type

[TylerBrinkley]

Consider the following code.

public class Singleton
{
    public static Singleton Instance { get; } = new Singleton(DefaultSettings);

    public static string DefaultSettings { get; } = "The settings";

    public string Settings { get; }
    
    private Singleton(string settings)
    {
        Settings = settings;
    }
}

One might expect Singleton.Instance.Settings to be equal to "The settings" but since Instance references DefaultSettings which is declared after Instance, results in null in my testing. If I declare DefaultSettings above Instance then I get "The settings".

To reduce these issues I propose that warnings be added to recommend initializing the fields or properties within a constructor when referencing other fields or properties that may have not been initialized yet. This warning should apply to both static and instance field or property initializers.

Updates

• Removed language about beforefieldinit and switched to proposing a warning instead of a compilation fail.
• Added language that the warning should apply to both static and instance field or property initializers.

[HaloFour]

Might be a candidate for warning waves, but I don't see the compiler ever being modified to make this illegal.

[svick]

their initializing is lazy due to the beforefieldinit attribute from not including a static constructor

If I include an empty static constructor, the behavior doesn't change. So I don't think this is related to beforefieldinit.

the behavior is undefined

It's not. The spec says (emphasis mine):

The static field variable initializers of a class correspond to a sequence of assignments that are executed in the textual order in which they appear in the class declaration.

[DavidArno]

To prevent these issues I propose that the language should be modified to disallow referencing other static fields and properties within the same type from static initializers except for constants and force users to use a static constructor instead.

This would be a breaking change. The language team are highly adverse to introducing breaking changes unless the benefits offered seriously outweigh the pain of breaking existing code. This proposal is extremely unlikely to happen therefore.

[TylerBrinkley]

I've updated the proposal to add a warning instead of inducing a compilation fail and added language that this should apply to both static and instance field or property initializers.

[sharwell]

@TylerBrinkley This would be a great candidate for an analyzer in the meantime.