Warn when readonly auto-prop is left uninitialized?

[john-cd]

Am I missing something or is there truly no warning / suggestion if you leave a readonly property uninitialized? This is rarely what one wants, except maybe for simple value types.

using System;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            var c = new C();
            Console.WriteLine(c.P);
            Console.ReadLine();
        }
    }

    class C
    {
        public C()
        {
            // if you forget to initialize P = "test";
        }

        public string P { get; }  // there is no warning
    }

}

[benaadams]

You don't need to initialise class members; this is fine too

    class C
    {
        public C()
        {

        }

        public string P; // there is no warning
    }

You need to initalize function locals and struct members; but classes are allocated from zeroed heap space so everything is set to default/null/zero if you don't set them.

[jnm2]

@benaadams you don't need to, but what's the likelihood that you meant to never initialize since it's immutable? You may as well have written

    class C
    {
        public string P => null;
    }

It's probably a mistake.

[benaadams]

Fair point, well made :)

[john-cd]

Yes, field / props left uninitialized by mistake are a big source of NRE.

These bugs are easy to find but I would rather avoid the recompile cycle :-)

[CyrusNajmabadi]

You could easily write a roslyn analyze to flag this for yourself :)

[agocke]

@john-cd I think @CyrusNajmabadi's suggestion isn't bad to unblock yourself, but I agree that this warning should have always been present.

Unfortunately, it will be quite difficult to add any new warnings until we finish "warning waves" (allowing us to add warnings without breaking existing customers who have /warnaserror turned on).

[john-cd]

What about a "suggestion" similar to what you get e.g. if a property / method is not properly capitalized?

[svick]

@benaadams Except you do get a warning in that case:

Warning CS0649 Field 'C.P' is never assigned to, and will always have its default value null

[alrz]

Unfortunately, it will be quite difficult to add any new warnings until we finish "warning waves" (allowing us to add warnings without breaking existing customers who have /warnaserror turned on.

@agocke

This is probably a little off topic, but how is that a breaking change when it's an opt-in feature? I mean, introducing yet another flag for warning waves doesn't make any difference. we're most likely going to add more warnings under "warning waves" over time so that itself is not backward compatible with /warnaserror turned on.

[jnm2]

And as I never tire of pointing out, since people keep agreeing with me, the people that want warnings-as-errors are the people that want to be broken by things like this. Warnings-as-errors are for when you are micromanaging the quality of code. I turn it on whenever the assembly is past primary development.

[gafter]

The language specification generally does not mandate warnings. It sounds more like a compiler or analyzer request, which would be more appropriate in the Roslyn repo.

[alrz]

what is the difference between IDE provided warnings and "warning waves"? Just that the latter comes from the compiler itself?