Non-nullable init-only properties should not warn at declaration place

[ghord]

Just tried preview of new C#, and I've noticed one thing that could be improved.

When I declare class with init non-nullable properties:

   public record Test
   {
       public int Age { get; init; }
       public string Name { get; init; }
   }

I get a warning:
Non-nullable property 'Name' must contain a non-null value when exiting constructor. Consider declaring the property as nullable.

What I thought would happen, is that I would only get nullable warning in the place where I try to construct the object without setting properties:

//warn: Name is non-nullable and not set
var test1 = new Test { Age = 1};

//no warning: Name is set to non-null value
var test2 = new Test { Age = 2, Name = "test" };

This would effectively reduce the need to use nullable annotations on properties that are never really intended to be null, but you have to annotate them anyway in order to satisfy the analyzer.

Any thoughts?

[ghord]

Just so you know, it could create issues around passing the class to generic code with new() constraint, where class is constructed with new T():

T create<T>() where T : new() => new T();

//test.Name is null anyway here
var test = create<Test>();

I think this is an issue, but could be resolved with further language work (for example enabling call create<Test> { Name = "test" })

[davidroth]

Yeah, the current situation is suboptimal when using NRTs.
C# 10 might solve this by introducing required properties. See: [Proposal] Required Properties

[canton7]

You're not the only one. Also see the arguments made by myself and @HaloFour in #2328

[erik-kallen]

One could argue that these types should not have a default constructor, since the default constructor would put the object in an invalid state.
For example, those types could have a constructor defined as:

public Test(DummyArgumentType _) {}

and the compiler could automatically add that dummy argument to any explicit call to new Test { Name = "X" }, but it would not fulfill the new() constraint

[ghord]

@erik-kallen The code that such classes appear the most for me are simple data objects, where usually you have multiple data properties (for example 20+) which you have to copy from somewhere else. Writing constructors with that many arguments is annoying and error prone.

[erik-kallen]

I did not suggest you write those constructors. I suggested that the compiler should do something to remove the default constructor for those types so they are not usable with the new() constraint. I actually opened an issue about this, #2830