Proposal: Introduce new<BaseType> Constraint

[NigelBess]

Summary

Introduce a new generic constraint for C#, tentatively called new<BaseType>, that ensures a type T can be constructed in the same way as BaseType—including matching constructor signatures and satisfying all required members.

Motivation

Required Members

In C# 11, required members can make the existing new() constraint insufficient if a subclass has extra required members or a constructor signature that deviates from its base.

Generic Reusability

Generic methods often need to “new up” objects that precisely conform to a base type’s construction pattern, ensuring consistency and avoiding runtime exceptions.

Better Static Guarantees

Without such a constraint, developers must fall back on factory delegates or reflection—both less direct and more prone to errors. A stronger constraint provides clearer intent at compile time.

Detailed Design

New Constraint Form

where T : new<BaseType>

Compiler Enforcement

• T must expose at least the same public constructors as BaseType (including a parameterless one, if BaseType has it).
• T may not introduce additional required members.

Compile‐time Errors

Any mismatch in required members or constructor signatures causes a compile‐time error when applying new.

Example In a Real World Use-Case

// Suppose Cylinder defines required members and has a parameterless constructor.
public class Cylinder
{
    public required double RadiusMm { get; set; }
    public required double LengthMm { get; set; }
    public Cylinder() {}
}

// Each of these implementations would be fleshed out further if needed:
public class XAlignedCylinder : Cylinder { }
public class YAlignedCylinder : Cylinder { }
public class ZAlignedCylinder : Cylinder { }

public enum Orientation
{
    XAligned,
    YAligned,
    ZAligned
}

// Example: build a cylinder according to its orientation.
Cylinder BuildCylinderFromBoundingBox(double x, double y, double z, Orientation orientation)
{
    return orientation switch
    {
        Orientation.XAligned => BuildCylinder<XAlignedCylinder>(y, x),
        Orientation.YAligned => BuildCylinder<YAlignedCylinder>(x, y),
        Orientation.ZAligned => BuildCylinder<ZAlignedCylinder>(x, z),
        _ => throw new Exception(),
    };
}

// Proposed usage of new<BaseType>
Cylinder BuildCylinder<T>(double diameter, double length)
    where T : new<Cylinder>, Cylinder
{
    var result = new T
    {
        RadiusMm = diameter / 2,
        LengthMm = length
    };
    return result;
}

Drawbacks

• Adds complexity to generics and constructor constraints.
• Requires the compiler to verify constructor signatures and required‐member sets, which may not be trivial.

Additional Concerns

• Handling abstract classes remains ambiguous (e.g., where T : new), possibly needing an additional constraint syntax if MyAbstractBase cannot be directly constructed.

Alternatives

Automatic Enforcement: Simply enforce the initialization of required properties when where T : BaseType, new() is used. However, this might require deeper compiler changes or could silently break existing code.

Conclusion

A new constraint would offer compile‐time guarantees that a generic type parameter can be constructed exactly like its base type, particularly for required members. This addition aligns with C#’s expanding use of required members, providing safer, more expressive generics and addressing the widespread issue of ensuring correct subclass initialization.

[colejohnson66]

What benefits does this provide over the existing where T : new() constraint? What you're proposing is already possible with where T : Cylinder, new().

[KennethHoff]

new() only works for types that:

1. Have a public parameterless constructor

2. Only has optional properties (read: no required properties)

Static abstract factory methods would work here. However, as of right now you can only have static abstracts on interfaces.

[AndersKehlet]

An interface with named constructors would work fine for the given use-case though, wouldn't it?

[bblazik]

Great proposal, dunno if it doesn't collide with other things like require, but for sure solves a problem that has been in discussion since 2016... or even further..