Proposal: Generic constructors

[dmitriyse]

public class MyClass
{
   // Currently it's impossible.
   public MyClass<T>(T myParam)
   {

   }
}

public class MyGenericClass<T>
{
   // Currently it's impossible.
   public MyGenericClass<U>(U myParam)
   {

   }
}

public void ConstructorUsageSample()
{
      // Implicit usage
      MyGenericClass<T> myVar = new MyGenericClass<T>("Test");
      MyClass myC = new MyClass("Test");

     // Explicit usage !!! SHOULD BE VERY RARE CASE !!!
     MyGenericClass<T> myVar1 = MyGenericClass<T>.New<string>("MyTest");
     MyClass myC1 = MyClass.New<string>("Test");
     // Or
     MyClass myC1 = new<string> MyClass.New("Test");

     // Explicit usage can be replaced by implicit usage with cast
   
      object myObjString = "Test";
      MyGenericClass<T> myVar2 = new MyGenericClass<T>((string)myObjString);
      // Here we have problems in a case of two classes MyClass and MyClass<T>
      MyClass myC2 = new MyClass((string)myObjString);
}

Constructor is just a method. So probably we can extend C# compiler, Reflection API and probably CLR to allow generic form of a constructor.

This proposal helps to compact a code like that

// My current approach
public class MyClass
{
     private MyClass()
     {
     }
     public static MyClass New<T>(Func<T, Task> func)
     {
             var instance = new MyClass();
             instance.Init(func)
             return instance;
     }
     private void Init<T>(Func<T, Task> func)
     {
           //Actual construction.
     }

     public static MyClass New<T1, T2>(Func<T1, T2, Task> func)
     {
             var instance = new MyClass();
             instance.Init(func)
             return instance;
     }
     private void Init<T1, T2>(Func<T1, T2, Task> func)
     {
           //Actual construction
     }
}

To

public MyClass
{
      public MyClass<T>(Func<T, Task> func)
      {
      }

      public MyClass<T1, T2>(Func<T1, T2, Task> func)
      {
      }

      public MyClass<T1, T2, T3>(Func<T1, T2, T3, Task> func)
      {
      }
}

[alrz]

class C<T> { public C<U>() {} }

How would you instantiate such class?

[yaakov-h]

How would you differentiate between class C { public C<T>() {} } and class C<T> { public C() {} ) ?

[dmitriyse]

@alrz very good question.

public class MyClass<T>

    public MyClass<U>()
    {

    }
}   
// Explicit call requires some new syntax required (ugly):
var myInstance = new MyClass<int><string>("MyTest");
// little bit better.
var myInstance = new<string> MyClass<int>("MyTest");

// Implicit form works good.
var myInstance = new MyClass<int>("TEst");

[dmitriyse]

How would you differentiate between class C { public C() {} } and class C { public C() {} ) ?

Compiler should disallow parameter-less generic form of constructor.

[DavidArno]

@dmitriyse,

Could you supply an example of how this would be used, as at first glance, it seems a pointless feature?

[dmitriyse]

It can be implemented just as C# syntax sugar.

public class MyClass
{
   // Currently it's impossible.
   public MyClass<T>(T myParam)
   {
         // Constructor content
   }
}

// Translates by Compiler to
public class MyClass
{
     private MyClass()
     {
     }
     [Constructor]
     public static MyClass __constructor<T>(T myParams)
     {
            var instance = new MyClass()
            instance.__constructorBody(myParams);
     }
     private void __constructorBody<T>(T myParam)
     {
            // Constructor content.
     }
}

[DavidArno]

Sorry, I'm not sure my question was very clear. I'm not so worried about how it could be implemented, more what would you use it for? As MyClass would have no knowledge of type, T, then myParam could only be used inside the constructor. What use-case would there be for that, that isn't already covered by simply making T a type parameter on MyClass?

[dmitriyse]

@DavidArno for example if you want to allow to build object from Func or Action with variable parameters.

public MyClass
{
      public MyClass<T>(Func<T, Task> func)
      {
      }

      public MyClass<T1, T2>(Func<T1, T2, Task> func)
      {
      }

      public MyClass<T1, T2, T3>(Func<T1, T2, T3, Task> func)
      {
      }
}

I am writing DI container, and there are many places where it can be useful.

It's not hard to workaround, but this feature can make things simpler.

// My current approach
public class MyClass
{
     private MyClass()
     {
     }
     public static MyClass Create<T>(Func<T, Task> func)
     {
             var instance = new MyClass();
             instance.Init(func)
             return instance;
     }
     private void Init<T>(Func<T, Task> func)
     {
           //Actual construction.
     }

     public static MyClass Create<T1, T2>(Func<T1, T2, Task> func)
     {
             var instance = new MyClass();
             instance.Init(func)
             return instance;
     }
     private void Init<T1, T2>(Func<T1, T2, Task> func)
     {
           //Actual construction
     }
}

[dmitriyse]

I updated topic with more convenient explicit construction syntax.
The same idea as for delegates where we can do myDelegateVar("abc", 10) and myDelegateVar.Invoke("abc", 10).

But for constructors inplace of Invoke we can use "New" method name convention.

[DavidArno]

OK, I get what you are aiming at now (though I'm still intrigued as to what //Actual construction does as the class knows nothing about the types.

How about an alternative, where constructors can specify a default type for one or more of the type parameters, removing the need to specify them when creating an instance?:

public MyClass<T1,T2,T3>
{
    private readonly Func<T1, T2, T3, Task> _func;

    public MyClass<T1, Unit, Unit>(Func<T1, Task> func) => _func = (x, _, _) => func(x);

    public MyClass<T1, T2, Unit>(Func<T1, T2, Task> func) => _func = (x, y, _) => func(x, y);

    public MyClass<T1, T2, T3>(Func<T1, T2, T3, Task> func) => _func = func;
}

var a = new MyClass<int>(async x =>...);
var b = new MyClass<int, int>(async (x, y) =>...);
var c = new MyClass<int, int, int>(async (x, y, z) =>...);

[SamPruden]

@DavidArno

I actually quite like this idea, have briefly considered it a few times before myself. Regarding your question about what //Actual construction does, the most obvious scenario is when you've got multiple parameters. Something like this:

class Foo
{
    private readonly int id;

    public Foo<T>(T item, Func<T, int> itemIdFuncServiceThing)
    {
        this.id = itemIdFuncServiceThing(item);
    }
}

Obviously this is a silly simple toy example, but I've definitely made generic factories for non-generic types before, this is basically just tidying up the factory syntax.

Another (slightly strange) scenario I hit fairly recently was an object that did some internal reflection work and only needed an instance of Type. Imagine something like this:

class ReflectionWrapper
{
    // This type should always implement ISomeRequiredInterface
    private readonly Type type;

    public ReflectionWrapper<T>()
        where T: ISomeRequiredInterface
    {
        this.type = typeof(T);
    }
}

The implementation I have right now has a private constructor that takes a Type and a public static Create<T>() method. It's not the ugliest thing ever, but this would be a nice little bit of tidying up.

[HaloFour]

Constructor is just a method. So probably we can extend C# compiler, Reflection API and probably CLR to allow generic form of a constructor.

Constructors aren't normal methods. I doubt that the CLR offers support for generic constructors at the time being.

And I still completely don't get the use case. It seems completely esoteric. If you're trying to write something like factory bindings for a container there are plenty of syntactic options available to you which are succinct and allow the compiler to infer the generic type arguments.

[Mafii]

public class MyClass
{
   // Currently it's impossible.
   public MyClass<T>(T myParam)
   {

   }
}

Isn't this the same as:

public class MyClass<T>
{
   // Currently that's possible.
   public MyClass(T myParam)
   {

   }
}

What's the exact advantage of your code then?

[dmitriyse]

// This base class is required to uniform access to MyClass<T> family.
public class MyClass
{
    public abstract List<MyInfo> SomeDataFromGenericArguments {get;}
}

public class MyClass<T>: MyClass
{
   // Currently that's possible.
   public MyClass(T myParam)
   {

   }
}

That's all about simplicity, like many other C# proposals.

[Mafii]

@dmitriyse so it could be a simple compiler solution not touching the clr?

My two examples would be interchangeable then.

Is that something that would make sense to you?

I just don't really see the true value of it. But I see why you'd prefer it.

[SamPruden]

class SomeClass
{
    public static SomeClass Create<T>(T whatever)
    {
    // ...
    }
}

This is already a pretty common pattern. What if the compiler just gave us some by-convention syntax sugar and let us call these functions with the constructor syntax? And optionally it could go the other way as well and let you write them like constructors and have it output the static Create() methods.

That would nicely maintain full compatibility with the other languages, work with existing libraries, and be pretty lightweight to implement.

It wouldn't have to be only generic methods either, any static method called Create, that returned the type of the class of which it's a member, could be called with constructor syntax. You'd have to work out how to handle signature clashes with actual constructors (probably just give constructors priority) but otherwise I can't see any reason why that wouldn't work. I am in desperate need of sleep though, so this may be nonsense.

We already have the Create pattern and it works fine, but when you think about it it is usually a workaround for something that constructors lack rather than a decision made for API niceness. I can see this making the language feel slightly more cohesive.

[dmitriyse]

I agree with your suggestion. But pay attention to "this".

class SomeClass
{
    public static SomeClass Create<T>(T whatever)
    {
         // Where my lovely "this."
    }
}

Please see this comment #266 (comment)

[SamPruden]

@dmitriyse Ahh yes, I hadn't thought of that, that does complicate things somewhat. For calling existing Create methods with the constructor syntax that obviously isn't relevant, but going the other way is a little tricky.

I don't think the way you've got it in that comment quite works really, either. Off the top of my head, there are two things constructors can do, that other methods can't: write to readonly fields, and call other constructors. An ideal solution would allow both of these.

Calling other constructors is probably perfectly doable, that would just be a case of choosing a constructor to use to create the instance in the first place. I think a constructor that was going to compile out to Create would have to be required to call : this() anyway, though the default constructor could probably be implied.

Setting readonly fields outside of the constructor is also (I believe) possible. Yes, I just tested it, it works.

So, given all of that, this:

class SomeClass
{
    private readonly Type type;

    // Normal constructor, it's the default but I'm being explicit to show that it's required
    private SomeClass() {}

    public SomeClass<T>() : this()
    {
        this.type = typeof(T);
    }
}

Should be able to compile into this:

class SomeClass
{
    private readonly Type type;

    // Normal constructor, it's the default but I'm being explicit to show that it's required
    private SomeClass() {}

    public static SomeClass Create<T>()
    {
        // Creates the instance from a real constructor
        // This is aliased as this in the constructor syntax
        var instance = new SomeClass();

        // This can probably be done nicely in IL, but worst case a readonly field can be set by reflection
        typeof(SomeClass).GetField("type").SetValue(instance, typeof(T));

        return instance;
    }
}

Have I missed some obvious thing here?

[HaloFour]

@TheOtherSamP

Having a compiler feature require compiler hacks that render the assembly unverifiable sounds like a "Bad Idea"™. There is no valid IL to accomplish that either.

[benaadams]

Are you going to get type collision as

class SomeClass
{
    public SomeClass<T>(){}
}

class SomeClass<T>
{
    public SomeClass(){}
}

are two different classes and told apart by the constructor invocation; if you gave the non-generic class SomeType a constructor that took a type T; which class of the two classes is being instantiated by the following?

var myClass = new SomeClass<T>();

[SamPruden]

@HaloFour

Oh okay then, I'll bow to your superior knowledge on this one, the compiler and IL really aren't my areas of expertise. I was assuming that the ability to change readonly fields via reflection was in the spec, but it sounds like you're suggesting that it's just an implementation detail.

Does de-serialisation not already write to readonly fields? If it's already done somewhere else then it feels defensible here.

[dmitriyse]

The only things we can do now - is wait for votes counter to reach some valuable amount.
It's possible to implement somehow, with or without CLR improvement.

Currently we will produce boilerplate factory methods code by hands.

[SamPruden]

@benaadams A couple of the comments above (#266 (comment)) were using the var a = new<T> SomeClass(); syntax which I quite liked.

[dmitriyse]

@benaadams good catch.

[dmitriyse]

var a = new<T> SomeClass(); syntax which I quite liked.

@TheOtherSamP please vote :)

[gafter]

Java supports generic constructors, though the syntax is slightly different. I've never seen anyone (other than me) writing a generic constructor (other than to test the compiler), but Java should, in theory, provide a rich library of use cases demonstrating why this proposal would be beneficial. Can anyone suggest one such example?

[TonyValenti]

Hi All,
I have a library that I work with that is very generic heavy. Here is a methodology that I've used to simplify working with generics, type inferencing, and such. It works great for me.

You'll notice that it lets you change/specify generic parameters individually as well.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp1 {
    class Program {
        static void Main(string[] args) {

            var C =
                GenericClass
                .WithT<String>
                .WithU<int>
                .Create("Hello Word!", 42)
                ;

            var D =
                GenericClass
                .Create("Hello", 42)
                ;

        }
    }




    public class GenericClass : GenericClass<Object, Object> {
        public static GenericClass<T, U> Create<T, U>(T Value1, U Value2) {
            return new GenericClass<T, U>(Value1, Value2);
        }
    }

    public class GenericClass<T, U> {

        public class WithT<NewT> : GenericClass<NewT, U> {

        }

        public class WithU<NewU> : GenericClass<T, NewU> {

        }



        public T Property1 { get; set; }
        public U Property2 { get; set; }

        public GenericClass() : this(default(T), default(U)) {

        }

        public GenericClass(T Value1, U Value2) {
            this.Property1 = Value1;
            this.Property2 = Value2;
        }

        public static GenericClass<T, U> Create() {
            return new GenericClass<T, U>(); 
        }

        public static GenericClass<T, U> Create(T Value1, U Value2) {
            return new GenericClass<T, U>(Value1, Value2);
        }

    }


}

[dmitriyse]

This approach can be useful. And I like it. But it does not solves this proposal.
The main problem is to have exactly one class with multiple generic constructors.
(Not hierarchy of classes).

[HaloFour]

No, having exactly one class with multiple generic constructors is your proposed solution. We're still trying to understand the actual problem enough to justify that it involves modifications to the language and likely to the CLR as well.

I can see the API that you'd like to have, but I'd like to understand more about what that class actually does with those generic parameters once it has been constructed. I can't imagine it doing anything meaningful, and certainly nothing beyond what is easily solvable today using static factory methods. The latter comes with the added bonus of already having good generic inference whereas constructors don't.