[Proposal] First-class constructors (constructor method group syntax)

[5cover]

This idea was discussed previously in #674, but no formal proposal was created. I’m proposing a concrete syntax and scope under the name ‘First-Class Constructors.’.

Summary

Enable constructor group conversions via a new syntax: TypeName.new or TypeName::new, allowing constructors to be referenced as first-class functions when their signature matches a delegate.

Motivation

In C#, methods can be passed as method groups when their signatures match a delegate type:

Func<string, int> parse = int.Parse;

But constructors — which are also functions — cannot be referenced in the same way:

Func<string, MyClass> f = x => new MyClass(x); // works
Func<string, MyClass> f = MyClass;             // doesn't compile

This forces developers to write redundant lambda expressions or introduce static factory methods:

Func<string, MyClass> f = x => new MyClass(x);       // Boilerplate
Func<string, MyClass> f = MyClass.Create;            // Requires extra method

We propose a new syntax that makes constructors first-class citizens in delegate assignments and functional contexts:

Func<string, MyClass> f = MyClass.new;         // clean and expressive
var list = items.Select(MyClass.new);          // concise and consistent

Design Proposal

Allow constructor group conversions through a constructor reference expression:

Func<...args..., MyType> f = MyType.new;        // or MyType::new

The compiler resolves this by finding a constructor in MyType whose parameters match the delegate's signature.

Matching Rules:

• Match by arity and type (standard overload resolution, akin to static methods)
• Return type must be assignable from the constructed type

Examples

Func<int, string, Person> f = Person.new;              // Resolves to Person(int, string)
Func<(int, string), Person> f = Person.new;            // Only works if Person has a constructor that takes a single (int, string) tuple
var people = rows.Select(Person.new);                  // Clean LINQ

Benefits

• Cleaner and more expressive functional-style code
• Reduces need for wrapper methods / static factories
• Improves language consistency (constructors as functions)
• Enables better tooling (hover info, go-to-def on .new)
• Aligns with modern languages (e.g., Java's Class::new, Kotlin's constructor references)

Drawbacks

• Introduces a new syntax rule (either :: or overloads . with a keyword)
• Could raise questions about consistency with method references vs constructor references

Alternatives

• Allow MyType as a constructor method group directly (e.g., items.Select(MyType)), but this is ambiguous and less expressive
• Continue using lambdas or static factories

Open Questions

• Should the syntax be MyType.new (consistent with static method access) or MyType::new (explicit and unambiguous)?
• Should new be a contextual keyword in this case?
• Could this be extended in the future to handle object initializers?

Prior Art

• Java: Person::new
• Kotlin: ::Person constructor references
• Scala: functions and classes can be used interchangeably in many functional contexts
• C# itself supports method group conversions, making this a natural extension

Conclusion

This feature would make constructors first-class, unlocking cleaner code and more expressive APIs, especially in LINQ-heavy or functional codebases. It's intuitive, consistent, and already proven in other modern languages. Let's make new feel like a first-class citizen in C#.

[HaloFour]

From the referenced discussion the syntax was never the problem, it was the behavior given that the compiler is forced to emit a separate lambda instance to wrap the constructor invocation. That would prevent such a feature from working well with, say, event registration/deregistration.

[5cover]

From the referenced discussion the syntax was never the problem, it was the behavior given that the compiler is forced to emit a separate lambda instance to wrap the constructor invocation. That would prevent such a feature from working well with, say, event registration/deregistration.

To clarify: the proposal intends for constructor references to behave like method group conversions — not as lambdas. In other words, MyClass.new would be treated like a method group, so the compiler would resolve it to a constructor method group and generate the appropriate delegate reference.

So just like someEvent += Console.WriteLine works for static methods, someEvent += MyClass.new would behave the same way. No extra lambda instances would be emitted — it would be semantically identical to the existing delegate binding behavior for methods.

[HaloFour]

The wrapping is necessary as constructors don't actually return any values. You can think of the invocation as follows:

MyClass o = alloc(MyClass);
o.new(parameters);

[5cover]

Oh, okay. So basically, at IR level, constructors aren't static methods.

Maybe the compiler could generate static helper methods for each constructor overload used via .new? These helpers would match the constructor signature and return the constructed instance:

private static MyClass __ctor__MyClass__string(string arg) => new MyClass(arg);

References to MyClass.new would bind to this helper method as a method group, fixing the event deregistration problem.

[timcassell]

It would have to be done in the runtime, not by the language, otherwise different assemblies would not have access to the same wrapper function.

[5cover]

Just to add a bit of personal context behind this proposal:

This isn’t about saving a few keystrokes – it’s about reducing small but constant friction in everyday code. When writing items.Select(x => new MyType(x)), I’m not only repeating myself – I have to introduce a variable x, give it a name that fits my naming conventions, and mentally parse boilerplate just to express a simple transformation.

Being able to write items.Select(MyType.new) instead would make the intent clearer, reduce noise, and align with how method group conversions already work. After hitting this pattern enough times in my own code, I finally got tired of it and realized this could be solved cleanly at the language level.

[Serdan]

A source generator that adds a named constructor to the type for each normal constructor should be trivial to write. I'd be surprised if it doesn't already exist.

[NN---]

Adding to prior art Nemerle language where constructor is simply name of the class allowing writing: seq.Select(A).

[Serdan]

Same in F#

type T(number: int) = class end

let f = [ 1; 2; 3 ] |> Seq.map T

[NN---]

Both come from ML and have many similarities in design.