Proposal: Extend generic type new() constraint with parameter types

[devedse]

From @devedse on October 12, 2016 20:20

Background

Currently C# allows its users to apply the "new()" constraint on methods accepting a generic type to let the compiler know it has a parameter-less constructor.

The following example shows 2 'random generators' that implement the IRandom interface that are being created and then used to return data:

class Program
{
    static void Main(string[] args)
    {
        var randomData1 = CreateRandomData<FastRandom>(10);
        var randomData2 = CreateRandomData<CryptoRandom>(10);
    }

    public static IEnumerable<int> CreateRandomData<R>(int length) where R : IRandom, new()
    {
        var randomGenerator = new R();
        for (int i = 0; i < length; i++)
        {
            yield return randomGenerator.Next();
        }
    }
}

public interface IRandom
{
    int Next();
}

public class FastRandom : IRandom
{
    public FastRandom()
    {

    }

    public int Next()
    {
        return 0;
    }
}

public class CryptoRandom : IRandom
{
    public CryptoRandom()
    {

    }

    public int Next()
    {
        return 1;
    }
}

Problem

Currently it's not possible to provide a parameter (e.g. a seed) to the constructor of the 'to-be created' random generators. The current solutions would be:

1. Use reflection to call the constructor and passing the argument to it. (Disadvantage: Not compile time safe)
2. Use a factory and do a switch case on the different types of implementations of the IRandom interface. Then return a new instance of the found match. (Disadvantage: Need to extend Factory every time a new class implements IRandom)
3. Implement an additional method on the interface (and thus implementing classes) Initialize(int seed); which will initialize the class and set it up. (Disadvantage: Having to do 2 method calls for something that's normally done in the constructor.)

Solution: parameterized new()

My proposed solution would be to also accept parameter types in the new() constraint. E.g. the new(int) in the following line of code:

public static IEnumerable<int> CreateRandomData<R>(int length) where R : IRandom, new(int)

This would make the complete solution look something similar to this:

class Program
{
    static void Main(string[] args)
    {
        var randomData1 = CreateRandomData<FastRandom>(10);
        var randomData2 = CreateRandomData<CryptoRandom>(10);
    }

    public static IEnumerable<int> CreateRandomData<R>(int length) where R : IRandom, new(int)
    {
        var randomGenerator = new R(50);
        for (int i = 0; i < length; i++)
        {
            yield return randomGenerator.Next();
        }
    }
}

public interface IRandom
{
    int Next();
}

public class FastRandom : IRandom
{
    private int seed;
    public FastRandom(int seed)
    {
        this.seed = seed;
    }

    public int Next()
    {
        return 0 + seed;
    }
}

public class CryptoRandom : IRandom
{
    private int seed;
    public CryptoRandom(int seed)
    {
        this.seed = seed;
    }

    public int Next()
    {
        return 1 + seed;
    }
}

Copied from original issue: dotnet/roslyn#14461

[devedse]

From @dsaf on October 12, 2016 21:24

This seems to be a duplicate of #2206 which is a shame because your version is also well-written. On the upside it's already in 1-Planning state :).

[devedse]

Ah :), well, my goal to get this implemented would still be resolved then.
Any idea how long it usually takes for an item to go from 1-Planning to Implemented / Released?

[devedse]

From @dsaf on October 13, 2016 16:47

No idea. Let's say I wouldn't expect it next year.

[devedse]

From @timopomer on November 28, 2016 0:55

@devedse i know this issue is old, but just in case you wanted to make this you can use (R)Activator.CreateInstance(typeof(R), length)

[devedse]

Yeah, that's indeed one of the workaround you can use for now. However I would like to do this type safe at compile time :).

[Mafii]

Well written Proposal. I would love to see this in the language. More compile time safety like this makes big codebases easier to maintain.

[orthoxerox]

Some other potential solutions for this:

1. Abstract factory:

public interface IRandomFactory
{
    IRandom Create(int length);
}

public struct FastRandomFactory : IRandomFactory //being a struct is important
{
    public IRandom Create(int length) => new FastRandom(length);
}

public static IEnumerable<int> CreateRandomData<F>(int length) 
    where F : IRandomFactory, struct
{
    var randomGenerator = default(F).Create(length);
    for (int i = 0; i < length; i++)
    {
        yield return randomGenerator.Next();
    }
}

2. Waiting for shapes (they will solve a generalized problem of requiring specific methods)

3. Extending interface definitions to support constructors:

public interface IRandom
{
    public IRandom(int length);
    ...
}

[jnm2]

The thing I'm worried about is that new(int, string) has no semantic meaning. Types that aren't meant to match will match. Also suppose you need to refactor to start taking three parameters? All your method constraints are coupled to the very specific signature and all will break, whereas a factory interface or custom delegate are named and separate that coupling away from each usage quite nicely.

[TahirAhmadov]

The thing I'm worried about is that new(int, string) has no semantic meaning.

I can see how that's a problem with delegates - you can assign any method to the delegate, even if it's not a semantic fit. However, in this case, we're talking about constructors only; the context is limited enough - the semantics are "create new object".

Types that aren't meant to match will match.

That's very unlikely to happen; you use base class/interface constraints, as needed, to narrow the pool of potential generics. It's important to remember that this constraint is not meant to restrict types, rather it's meant to allow a type safe way to create objects.

Also suppose you need to refactor to start taking three parameters? All your method constraints are coupled to the very specific signature and all will break, whereas a factory interface or custom delegate are named and separate that coupling away from each usage quite nicely.

The same number of breaks and required fixes will ensue with delegates and factories. Fundamentally, you used to call a method with 2 arguments; and now need to change it to call 3 arguments. Whether that method is a delegate, a factory, or a constructor, doesn't change the amount of work of making this change. Furthermore, it's even more work - now you have to write and maintain the delegate/factory stuff, in addition to the constructor.

[Pzixel]

Allowing interfaces to have static methods, or add new interfaces on types themselves could solve this. Create an instance of class just to call a method which returns new instance of this class. That's sounds weird. This is why we cannot have interface IParseable<T> where we could have a method T Parse(string input);, because we don't want to create an instance just to create an instance and simultaneosly we can't invoke T.Parse because we don't constraint the type itself, but only its instance methods...

I know about implementation of generics with __Cannon so I don't have a good solution of how it could be implemented. However, we probably might add costructors to interfaces so I'd be:

public interface ICreatable
{
    string GetName();
    new(string name);
}

[RikkiGibson]

Interfaces now can have static abstract methods :)

[jnm2]

@Pzixel Already gave my thoughts on that in #837.

[Pzixel]

@jnm2 shapes probably might solve this? I mean:

public shape CreatableWithSeed
{
    new(int seed);
}

public static IEnumerable<int> CreateRandomData<R>(int length) 
   where R : IRandom, CreatableWithSeed
{
    var randomGenerator = new R(50);
    for (int i = 0; i < length; i++)
    {
        yield return randomGenerator.Next();
    }
}

[gafter]

This is part of a proposal being tracked at #110 which is under active development at MSR (Microsoft Research).

[ActivistInvestor]

@jnm2: The thing I'm worried about is that new(int, string) has no semantic meaning

I don't recall ever having used new() without an additional type constraint.

How does using new() without a type constraint have any more semantic meaning than using the theoretical or proposed parameterized new(...) without also using a type constraint?

[jnm2]

I don't recall ever having used new() without an additional type constraint.

It's common as part of a generic factory method (in the same spirit as new Lazy<Foo>().Value).

How does using new() without a type constraint have any more semantic meaning than using the theoretical or proposed parameterized new(...) without also using a type constraint?

This is an excellent point. I would answer that it's obvious with new() that you get the default construction of whatever T is, whether constrained or not. With new(string, int), it's not obvious what the first and second arguments mean, whether T is constrained or not. What choices are you making with that string and int? What are you causing to happen?

You don't really have that question with new T(). You know you're getting the default construction of T.

[ActivistInvestor]

This is an excellent point. I would answer that it's obvious with new() that you get the default construction of whatever T is, whether constrained or not. With new(string, int), it's not obvious what the first and second arguments mean, whether T is constrained or not. What choices are you making with that string and int? What are you causing to happen? You don't really have that question with new T(). You know you're getting the default construction of T.

I don't see how that differs from what one must do today (use reflection to construct instances via calls to a parameterized constructor).

This is widely done now, except that the construction is done via reflection, and the consumer of the class that performs the construction has to understand what the arguments of the constructor they have to provide mean. The only difference between that, and a parameterized new() constraint, is that it becomes a compile-time error rather than a runtime error.

So, are you suggesting that what we must currently do today, we shouldn't do, because the meaning of the constructor's arguments aren't any more obvious than that of a parameterized new() constraint?

One way or the other, it requires documentation.

[darssy]

HI all,

Can we maybe revisit this and get some new insights if we would want or not want this to be implemented, as there's quite some people that have upvoted this.

@devedse considering how popular is this 10 year old question at stackoverflow, I would say it's not just "some people" ;)

I personally consider it useful as I found myself more than once in need of a parameterized new() solution. My 2 cents.

[devedse]

Hi all, It's been a while, but I just saw a notification drop in my mailbox so I thought I'd chip in again too. I still think this idea would be great to add.

As @Shadowblitz16 also mentioned, having this, simply makes sense. Having new() accept a parameter specification feels intuitive to me, especially since there's already ( ) in there.

I saw your approach regarding shapes as well but I think this could still be a strong addition since shapes seem to resolve a more difficult challenge we're running into.

In regards to @jnm2 's comment about it not having semantic meaning, can't we build it the same way that named tuple's solve this?:

private static (int Count, double Sum, double SumOfSquares) ComputeSumAndSumOfSquares(IEnumerable<double> sequence)
{
    var computation = (count: 0, sum: 0.0, sumOfSquares: 0.0);

    foreach (var item in sequence)
    {
        computation.count++;
        computation.sum += item;
        computation.sumOfSquares += item * item;
    }

    return computation;
}

That way you could have either one of these options:

Option 1:

    public static IEnumerable<int> CreateRandomData<R>(int length) where R : IRandom, new(int)
    {
      ...
    }

Option 2:

    public static IEnumerable<int> CreateRandomData<R>(int length) where R : IRandom, new(int seed)
    {
      ...
    }

Another way I wouldn't mind this issue to be solved is by having the option to define a constructor definition inside an interface. I mean, why do we have the ability to define methods but not constructors? To me it would make sense to have both. This might also have some more benefits when doing serialization / deserialization.

Option 3:

public interface IRandom
{
  IRandom(int seed);

  int Next();
}

public class Random : IRandom
{
  public Random(int seed)
  {
    ...
  }

  public int Next()
  {
    ...
  }
}

In my opinion, option 3 more closely follows the current C# spec.

I think either one of these options could be implemented in a way that would avoid the use of Activator.CreateInstance<T>()

Edit:
I have seen some backlash against Option 3 as people have stated that the constructor definition in the interface doesn't have anything to do with the implementing class. I do think that after reading through these that it would make more sense to go for Option 1 or 2. To me a constructor feels the same as a method in this sense, but since within C# we've made the decision to put differentiating logic to construct a specific instance of a class within the constructor, having an interface definition of this constructor wouldn't make sense.

Reference: #837 (comment) and #837 (comment)

[Pzixel]

It could be naturally solved if typeclasses come into the game so you can just write where T : New<int>, and there is no need for special syntax in the language. Waiting for #164

[devedse]

@Pzixel then you'd still have the problem that it doesn't have any semantic meaning though.

[Pzixel]

I don't get your idea. Could you elaborate? It looks like it's a complete replacement:

shape New<T> {
  static Create(T arg) -> this;
}

...

void Foo<TVal, TNew>(Tval arg) where TNew : New<TVal>, IBar {
  var newVal = TNew.Create(arg);
  newVal.Bar();
}

[devedse]

Ah that's what you mean, I haven't really checked out shapes enough. So with that solution you wouldn't be using the constructor, but rather a static method that creates an instance of the class with some parameters?

Could you maybe show an example how this would work for the example above with the Random instances?

[Pzixel]

No problem:

public extension NewRandom of Random : New<int>
{
    public static this Create(int arg) => new Random(arg);
}

public static IEnumerable<int> CreateRandomData<R>(int length) where R : IRandom, New<int>
{
  var randomGenerator = R.Create(50);
  for (int i = 0; i < length; i++)
  {
    yield return randomGenerator.Next();
  }
}

I'm also using a quite enhanced version of this proposal: #169 , but I think it's clear what do I mean.

[devedse]

@Pzixel, but in your example, why do you still include the : New<int>. You already specify in the Create method that there's an int argument right?

[Pzixel]

Because type inference in C# works this way (or to be more precise: it doesn't).

[darssy]

@devedse as I'm the one who "stirred the pot" I think that it might be better off if we keep the constructor in interface separate from the parametarized new() feature request. Otherwise it won't have a chance to make it to the language I'm afraid.

Now the question (IMHO always) is how can we draw some attention to this one so that it will have some chance to reach a future version of C#. C# 20 let's say -hope I wont be in pension by then.😅 As I see it, the popularity of the question in SO (where I actually landed this page from) can be an indicator of the usability of the feature.

[dogac00]

Any updates on when could this be available in C#?

[jnm2]

I think the general rule is that the answer to this question is always no.

[pzahra]

Let's step back a minute.

The goal we're trying to achieve here is simple: at some point within the body of this function, we may want to create a new instance of IRandom (providing it an implementing classname) and pass it a Seed int. That's all.

Here's the original function using a callback instead:
IEnumerable<int> CreateRandomData(CreateIRandomCallback create, int length)

delegate IRandom CreateIRandomCallback(int seed)

(of course you could use Func<int, IRandom> create instead of declaring a delegate type, but that's another discussion)

Usage:
values = CreateRandomData(seed => new CustomRandom(seed), 100);

Note that the end result doesn't even need to be generic. The function still has the ability to create a new instance of IRandom wherever/whenever it wants, using the signature it is expecting. On the other side, we're still providing it a classname, but we're also choosing the constructor. Maybe it's one that has additional default params we're not using; maybe we're specifying Seed as a property, or ignoring it entirely; maybe we're providing it with upper or lower bounds, or a tablename to query. Whatever the case: it gave us a Seed, we gave it an IRandom, and it continued doing whatever it does.

This is more flexible than the proposed generic constraint, doesn't require every implementer of IRandom to have a potentially breaking constructor, doesn't make use of reflection, doesn't require you to be the owner of every implementer, and is already fully supported.

[MithrilMan]

Ok it seems I expressed the same need https://github.com/dotnet/runtime/issues/68858

[jnm2]

If the language had this types, maybe that in combination with static abstract methods would fill the need and would allow a nominal rather than shape-based approach:

public void M<T>() where T : IFoo // instead of where T : new(...), now you have something with a specific meaning
{
    T instance = T.Create(someSemanticInfo: 42);
    // ...
}

// Having to declare the signature this way means that not all `new(int)`-shaped constructors are silently interchangeable
// regardless of what the parameters mean.
public interface IFoo
{
    public static abstract this Create(int someSemanticInfo);
}

[jnm2]

I see. If you did rename it string constructorArgument or something like that, then I'm no longer concerned. But the usefulness of this helper seems limited. If the argument(s) are just going to be passed through from the call site untouched, why not inline the if statement and the exception creation and throwing? The latter is far more flexible, too, allowing every combination of counts and types of arguments to be succinctly specified. You get intellisense, etc.

(Alternatively, https://github.com/safakgur/guard is pretty cool.)

[MithrilMan]

The point here is not about how to implement a Guard (I wouldn't use the example code in production as is), the concern here is about how to prevent to make use reflection and improve performance when there is the need to instantiate a generic with a constructor with parameters. We could argue about if the pictured scenario happens often or not but the code is out of scope.

Thanks anyway for the repo link, tbh I see the suggested library is fluent so it means it has always to allocate an object instance to be fluent, I'd prefer something more close to this instead https://github.com/ardalis/GuardClauses

[jnm2]

There will be the exact same reflection either way. where T : new() is implemented via Activator.CreateInstance<T>.

There are no allocations. From its readme:

If this looks like too much allocations to you, fear not. The arguments are read-only structs that are passed by reference. See the design decisions for details and an introduction to Guard's more advanced features.

[TahirAhmadov]

It's not implicit though. If you make a mistake in implementing IExceptionFactory for ArgumentNullException/whatever exception, you are explicitly passing message to paramName within the responsible exception class. If there is only a where T : new(string) constraint, then there is an implicit bug not located within the implementation of IExceptionFactory (Within the responsible exception class, or with roles and extensions, within code that has taken responsibility for this implementation.)

But you do explicitly use ArgumentNullException as the generic argument. I agree - there is not enough "visual feedback" - it's easier to make a mistake; however you know your type has a constructor which does not do what the receiving generic type expects.
Also, I don't see this as a frequent situation which would lead to numerous bugs. It's much more common to have domain specific types which don't have these kinds of constructor collisions. In fact, Argument***Exception is a notorious exception (pun intended) to the expectation of constructor parameters in BCL and definitely elsewhere in the C# ecosystem.
More importantly, though, even with this one minor caveat of Argument***Exceptions, this is still a better approach than either a) using Activator.CreateInstance directly, which is much more error prone, or b) writing a new factory interface and N types - one for each possible generic argument type; lots of make work.

There will be the exact same reflection either way. where T : new() is implemented via Activator.CreateInstance<T>.

That's a separate conversation. I don't know if this is optimized down the line or not (say, by JITter). Personally, I think it's due time to vastly improve this even in C# - it's easy enough to write IL which binds to the constructor as part of generic type initialization. Personally, I use a helper class which uses IL emit instead of CreateInstance which does just that - to be on the safe side.

[MithrilMan]

There will be the exact same reflection either way. where T : new() is implemented via Activator.CreateInstance.

At first I didn't belived it, I double checked on sharplab and I confirm what you say, I don't know why it doesn't have a better code to bind to the default constructor, hopefully it will be improved when the eventual new(string) will be a thing.

There are no allocations. From its readme:

If this looks like too much allocations to you, fear not. The arguments are read-only structs that are passed by reference. See the design decisions for details and an introduction to Guard's more advanced features.

Even if it's in the stack, it's anyway an allocation, it creates an object it has to be passed along the chain of fluent methods, spends CPU time and since I'd use Guards mostly for basic argument validation (null check, emtpy string, etc...) and they are used in hot paths, that performance penality matters (at least in performance critical services)

If I have to do domain entities validation and readability gained by a fluent syntax helps, then I'm fine using libraries like this or FluentValidation, anyway I'm going off track talking about guard and at the end there is no silver bullet anyway, it's a matter of context (the app type, if it's performance critical, the team skill/background? etc...)

Thanks for the convo

[koliyo]

Here is a factory example using the static abstract interface methods in C# 11, that seems to be a useful workaround, continued from what @jnm2 mentioned.

public interface IFactory<TSelf> where TSelf : IFactory<TSelf> {
  static abstract TSelf New(int i, string s);
}

public struct Foo : IFactory<Foo> {

  public static Foo New(int i, string s) {
    return new Foo(i, s);
  }

  public readonly int I;
  public readonly string S;

  public Foo(int i, string s) {
    I = i;
    S = s;
  }
}

public static class Maker {
  public static T Make<T>(int i, string s) where T : IFactory<T> {
    return T.New(i, s);
  }
}

But as @MithrilMan mentions, this only works if you are the owner of the target class.