Use constructors as method groups. Add the ability to use constructors as method groups when creating delegates

[jmaine]

Add the ability to use constructors as method groups when creating delegates.

This:
Func<object> f = Object.new;

would be similar to this:
Func<object> f = Object.StaticMethod;

as this:
Func<object> f = () => new object();

is similar to this:
Func<object> f = () => Object.StaticMethod();

A constructor used as a method group when creating a delegate will be act like using a static method group that returns the object that is being constructed when compiling.

[lachbaer]

I find this confusing, because it would allow every constructor to be used in this way. I prefer the current way to use an object factory by an explicit static (op-. extension) method named Create().

[yaakov-h]

I find this confusing, because it would allow every constructor to be used in this way.

Isn't that the entire purpose of this proposal/request?

[GeirGrusom]

Constructors cannot be bound to a delegate.

edit: to clarify, there is a CLR restriction in place.

[HaloFour]

This could be accomplished via syntax candy, though:

Func<MyClass> func = MyClass::new; // using Java method reference syntax
// compiled into
Func<MyClass> func = () => new MyClass();

[Joe4evr]

to clarify, there is a CLR restriction in place.

That sucks, but I recall @CyrusNajmabadi saying in another thread that he would like to see this (even suggested ClassName.new as the syntax just like this proposal since it's illegal to have a class member named new), so there's a possible Champion in the LDM team, at least.

And really, even if it was just syntax sugar as HaloFour suggests, it'd be pretty great.

[CyrusNajmabadi]

I would be fine with this if there is a clear thing this translates to in the CLR. And, specifically, we'd need a solution that could ensure the following would work properly:

x.SomeEvent += SomeType.new;
...
x.SomeEvent -= SomeType.new;

[lachbaer]

x.SomeEvent += SomeType.new;

Where should the result of 'SomeType.new', namely the newly created object, go?

[jnm2]

@lachbaer The result is returned from the invocation of the delegate which is backing the event. With multicast delegates, that's the value of either the last or the first invocation (I forget).

[bondsbw]

I'll also propose this syntax, for the sake of familiarity:

Func<MyClass> f = new MyClass;

[GeirGrusom]

@HaloFour how would you avoid the cross assembly issues?

[yaakov-h]

@GeirGrusom What cross-assembly issues?

[GeirGrusom]

new Func<string, string>(String.Copy) == new Func<string, string>(String.Copy)

This evaluates to true today. Imagine if the right hand was done in a different assembly (and it was a constructor instead). It would suddenly evaluate to false. And as @CyrusNajmabadi mentioned implied you wouldn't be able to unsubscribe to an event from across assemblies. It would introduce a very sneaky quirk. Or bug as I like to call it.

[HaloFour]

@GeirGrusom

True, the wrapping with a lambda would introduce that problem. But that's the only way that this feature can be introduced with only language changes. Constructors are instance void methods and you're not permitted (well, not supposed to) invoke them directly. To treat them like a static factory you'd need something to wrap the constructor.

While the event subscription situation does exist I'd wager that it would be exceptionally rare. Constructors don't fit in the normal convention for defining events, and events that return values, while technically legal in C# (not in VB.NET), are non-deterministic in multiple subscription scenarios.

[GeirGrusom]

To treat them like a static factory you'd need something to wrap the constructor.

Or CLR support.

[lostmsu]

I like @bondsbw's syntax more, if possible.
It is incorrect, that you can't define a member called new. Just do @new, and the bytecode will have it named new.

[ghost]

Func<MyClass> f = new MyClass;
This could act exactly the same as static functions work, and I can't think of any scenarios where this is currently valid syntax.

[jamesharling]

I was about to open an issue to suggest this feature. I would also favour @bondsbw's syntax, it is in keeping with both current constructor syntax and method group syntax.

I was surprised to find constructors not supported as method groups, something like the following feels like it should be supported C#:

public class StringWrapper
{
    public string Value { get; }

    public StringWrapper(string value) => Value = value;
}

var strings = new string[] { "foo", "bar" };

var wrappers = strings.Select(new StringWrapper);

[MarcSigrist]

I would welcome this feature in C#, because

• I have used it a lot in F#.
• Intuitively, it feels like one of the last "missing pieces", considering the strong trend to remove needless syntactic overhead from C#, such as e.g. with index initializers (C# 6.0), expression-bodied constructors (C# 7.0), using declarations (C# 8.0), "Extension Everything" (proposed), ...

From what I have seen so far, I would prefer @bondsw's syntax.

[Foxtrek64]

I think I would prefer Type::new or Type::ctor. If it's just syntax candy, it should fit really well with things like Select(Foo::new) -> Select(it => new Foo(it));

I think the only outstanding question would be overload resultion in case of multiple constructors, but that should be something that can be handled just like Select(Foo.SomeStaticMethod)

Select(new Foo) doesn't feel quite right, so I'd vote against that syntax.

Edit: @333fred points out that Foo:ctor could cause conflicts if you have an extern-aliased assembly named Foo and a type ctor in that assembly.