Constructor Method Reference Syntax

[Foxtrek64]

Not entirely sure what to call this idea, but essentially I want to expose a syntax that allows for method references to the ctor of a type. Consider the following example:

List<Foo> foos = [...];

var bars = foos.Select(Bar.FromFoo); // Overload detection identifies method FromFoo(Bar)

There is no corresponding syntax for identifying a constructor for the Bar type, leaving consumers to use foos.Select(it => new Bar(it));. This feels like a use case where it can be shortened, similiar to how it => Bar.FromFoo(it) can be shortened. However, foos.Select(new Bar) doesn't really make much sense syntactically and ctors are handled differently from method calls in this case anyways.

Syntax ideas:

• Bar:new or Bar::new as in Select(Bar:new) or Select(Bar::new). This involves adding a new symbol and meaning and carries with it all of the complexities of adding new symbols.
• Bar.Bar as in Select(Bar.Bar). This could get cumbersome for longer type names.
• A Bar.New() method, possibly created via code generation. Used as Select(Bar.New). Body would be weird to figure out for this one but one possible solution could be that it needs to find an equivalent ctor signature. In other words, New(string) would need a corresponding Bar(string) constructor.

Concerns:

• This would in theory allow for accessing static ctors, which may or may not be desirable in all situations.
  • This is certainly not desirable in situations where the static ctor could be called, but it may be useful for situations like nameof or reflection.
• Whatever syntax is chosen would need to be available for both classes and structs. The code generation version actually makes this easier to implement on structs, assuming we map to a public ctor defined on the type.
• Has anyone else actually run into the situation of needing this? I have personally been encountering it a lot and it's been a bit annoying to both function references and lambdas for constructors to the point where I've been introducing FromX() methods for types just so I can have that visual congruity. But maybe that's just me.

[TahirAhmadov]

#674

[AndersKehlet]

It's not just you, but I'd suggest that simply creating named constructors is a fine solution (named static methods on the type). A source generator to do this would be trivial.

[RikkiGibson]

If Bar.Bar is an option, why not just Bar. Today a type isn't valid in a context where a delegate value is expected anyway.