Allowing new() generic constraint to have some required members if the derived class has no extra required members

[eventblox]

Currently, if you try to create a generic constraint with a type that has required properties, you cannot use the new() constraint in the where clause. Consider the following definition:

TResponse _DoSomething<TResponse>
  where TResponse : SomeBaseWithRequiredMembers, new()
{
}

If you try to use the generic method as follows:

DerivedWithNoNewRequiredMembers _DoSomething<SomeDerivedWithNoNewRequiredMembers>();

...it will generate a compile-time error message along the lines of...

'XXXX' cannot satisfy the new() constraint on parameter 'YYYY' in the generic type or method 'ZZZZ' because 'ZZZZ' has required members.

That seems like overkill. I understand not being able to new a type via a default constructor if a derived type is passed as TResponse which has additional required members. The generic method won't know anything about those additional required members., so it can't properly "new" up the TResponse using the default constructor . However, given that generic constraints are validated at compile time, the compiler can detect if the derived class has no additional required members.

In such cases, the generic method has all the information it needs to populate the required members safely using the required properties in scope in the base class.

Could we not loosen this "required" member rule for the constraint in this case?

[siegfriedpammer]

You cannot know if the inheritance tree of a type is complete at compile-time. Assemblies may be dynamically loaded at runtime.

So checking for this is not possible... I think...

[eventblox]

Ok, so the concern is that the type used at compile time and passed as an argument to the generic might be different at runtime because a different assembly is loaded at runtime to provide the type?

I wonder if that is not the case with strongly named assemblies. You can't just drop in an alternate assembly in that case...

[the-avid-engineer]

Unless you don't have control over the type, you could use a static abstract method on an interface, have your type implement the interface, and use the interface as a constraint instead of the new() constraint. This would make it the responsibility of the type to deal with filling in required properties

public interface INew<T> where T : INew<T>
{
	static abstract T New();
}

public class MyClass : INew<MyClass>
{
	public required string MyProperty { get; init; }

	public static MyClass New()
	{
		return new MyClass() { MyProperty = "<DefaultValue>" };
	}
}

public void DoThingWithNew<T>()
	where T : INew<T>
{
	var obj = T.New();

	//... do whatever you need to do with obj
}

[eventblox]

What an interesting idea. Would also let me have a constraint that acts like a constructor that takes specific arguments as well (like New(string name, int age)).

Thanks for the suggestion. A C# 11 feature I didn't fully understand the ramifications of...

[thirstyape]

For reference, the [SetsRequiredMembers] from the documentation seems to be another option for this scenario.