Interface constructors

[UnoSD]

I was looking at this proposal from @devedse : #769

And it would be a nice language feature although, I agree with @jnm2 on his comment: #769 (comment) about the lack of semantical meaning

How about defining the constructor on the interfaces? That would solve both problems; it will allow parameters in constructors and the interface can specify the meaning with named parameters and a constructor that is bound to the interface meaning itself.

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
    {
        var randomGenerator = new R(50);

        for (int i = 0; i < length; i++)
            yield return randomGenerator.Next();
    }
}

public interface IRandom
{
    IRandom(int seed);
    int Next();
}

public class FastRandom : IRandom
{
    private int seed;

    public FastRandom(int seed) => this.seed = seed;

    public int Next() => 0 + seed;
}

public class CryptoRandom : IRandom
{
    private int seed;

    public CryptoRandom(int seed) => this.seed = seed;

    public int Next() => 1 + seed;
}

Haven't thought this through yet so please apologise if it has some evident pitfall.

For instance, I, for one, struggle with the idea of forcing a parameter on an interface that has potentially no effect on the public API output but it is just an internal implementation detail.

[Pzixel]

IMHO it has nothing to do with interface. For example, how compiler have to choose between different constructors? Meanwhile,

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

seems to be far more reasonable. And in this case IRandom is optional. For example:

    public static IEnumerable<R> CreateRandomData<R>(int length) where R : new(int)
    {
        var randomGenerator = new Random(50);

        for (int i = 0; i < length; i++)
            yield return new R(randomGenerator.Next());
    }

[vladd]

In the typical case, classes implementing the same interface nevertheless need different parameters in their constructors.

public class NoRandom : IRandom
{
    public int Next() => 0;
}

public class FastRandom : IRandom
{
    int seed, multiplier;
    public FastRandom(int seed, int multiplier)
    {
        this.seed = seed;
        this.multiplier = multiplier;
    }
    public int Next() { seed *= multiplier; return seed; }
}

public class CombiningRandom : IRandom
{
    IRandom source, index;
    int[] reservoir = new int[256];
    public CombiningRandom(IRandom source, IRandom index)
    {
        this.source = source;
        this.index = index;
        for (int i = 0; i < reservoir.Length; i++) reservoir[i] = source.Next();
    }
    public int Next()
    {
        uint nextIdx = (uint)index.Next() >> 24;
        int result = reservoir[nextIdx];
        reservoir[nextIdx] = source.Next();
        return result;
    }
}

Having a predefined constructor signature would require squeezing the parameters into the signature types, which isn't going to produce a good code. Let's not endorse bad coding patterns.

[StellarWolfEntertainment]

Not all implementations of an interface will require different constructors, especially if you take into account potential generics, for example if you were to define this (I don't know why you would need to, it's just the first example I thought of)

public interface IKeyValuePair<TKey, TValue>
{
    IKeyValuePair(TKey key, TValue value); // this constructor would apply to any combination of generics, and be *A* required constructor in any implementation of IKeyValuePair
}

[HaloFour]

This mixes contract with implementation, and only works if you're expecting exactly one implementation. As soon as you have differing implementations with different dependencies this "required constructor" becomes a liability, in that you are now forced to support construction with incomplete arguments for a necessary implementation.

[StellarWolfEntertainment]

I suppose I tend to think in reverse, where it seems that some people 'define' an interface, then define the various implementations of that interface, I write the implementations and work backwards towards the interface merging common behaviors and data into baser types, so for me if I define 10 implementations that could all be indicated by a single interface and they all share a constructor signature in common, I'd like to add that constructor to the basest type I can, an example of a time where one might use a 'required' constructor is to ensure that there is a constructor for a type that is intended to load external data from someplace else, eg from a file, now we want to either ensure a 'file path', or a 'Stream' is provided to satisfy the intended purpose of the interface.

[CyrusNajmabadi]

like to add that constructor to the basest type I can

This is where an abstract class is appropriate. Note you're not mixing contract with implementation. The interface remains the contract, the abstract class can provide a common impl.

[HaloFour]

I'd like to add that constructor to the basest type I can

Constructors aren't inherited. Even if you did require a constructor in an abstract base class, and each derived class is required to call it, there is no requirement that each derived class expose a constructor with that same signature. That's intentional, as if the language did require the same signature it'd be impossible (or extremely awkward) for any derived type to require more/different parameter than its base class.

[Opiumtm]

Most obvious and direct solution is to use "factory pattern".

Just define "factory interface"

public interface ISomething
{
    // ...
}

public interface ISomethingFactory<T> where T : ISomething
{
    T Create(int arg1, string arg2);
}

[jnm2]

What does this gain you over simply declaring a separate factory interface or custom delegate?
The separate factory interface makes more sense than including all the methods in one interface because the concerns are separate. You might want to use a caching factory in some places and a transient factory in other places while both factories return the same implementation.

Plus, like @vladd says there's the problem of different implementations needing extra constructor parameters which is almost a given.

[StellarWolfEntertainment]

There are plenty of times in which an implementation regardless of type might require otherwise identical constructors, I posted one example on the answer by @vladd, but there are other cases, an existing interface (but should admittedly be obsolete, since the system that used it is not advised for use, and itself has been obsoleted) would be the ISerializable interface where in order to properly implement it, it requires a constructor with a specific signature.

[Pzixel]

@jnm2 C# is a turing-complete language so you already can express anything, but it's better to have a language support than write factory of factory of adapter of facade. You wrote an entire factory just to invoke a constructor. It's a completly mechanical process and this is what compilers are good at.

[orthoxerox]

@jnm2 it's the same kind of request as the one about async constructors (#419). In both cases you can use a factory method, but bare factory methods are an antipattern in my opinion. You should construct objects using constructors, and it's an unnecessary limitation of the language that a constructor is a special method that always automatically allocates a new object. I would gladly welcome constructors that return cached instances, construct objects asynchronously etc.

Why can't the rules of object instantiation be a part of the interface? They are no different from the rules of interaction.

[HaloFour]

Constructors aren't virtual and aren't inherited behavior. It generally doesn't make any sense for them to be given each type has very different dependencies.

That said, I would imagine that shapes would satisfy this proposal.

[Pzixel]

@HaloFour constructors has defenitly inherited behaviour. It has been discussed already: #419 (comment) and dotnet/roslyn#6788 (comment) . I didn't invent any worthwhile solution but I defenitly think that we need more asyncish support in language and it's possible, but just not this obvious that it can be easily found.

Anyway, it's beside the point and proposed issue.

[HaloFour]

@Pzixel

What you are describing is not inheritance. Constructors are not inherited, which is why a derived class must invoke a parent constructor from its own constructor.

[Pzixel]

@HaloFour In this regard you're right, because I meant logical "inheritance".

[DavidArno]

I subscribe to the view that the need for a design pattern in code is an indication of a deficit in that language. Factory patterns are one such example. As @orthoxerox says, new really is very limited in C#: it returns a new instance of some type. In situations where a value singleton is needed, a cached value, or some other control over what type is provided to the caller, then factories are needed. I do not subscribe to the view that factory methods are anti-patterns though. They are genuine patterns: they provide a work-around to the language's limitations.

However, I do not see this proposal as addressing any of this. What parameters a class needs for its constructors is implementation specific. Binding all implementations to a specific constructor defined by an interface feels like a step in the wrong direction to me.

[UnoSD]

Another downside is that it may encourage people to use it for logic classes forcing either to "service-locate" dependencies or to avoid DI all together (although it is not a good argument not to add features, see local functions...).

Perhaps we could solve this in a different fashion, as having to write a factory to achieve this is of course good practice, but a lot of boilerplate in simple cases. User could rely on high order functions passing the factory method in, but that would make it even closer to the implementation in some cases.

[jnm2]

I don't understand why you'd ever expect to be able to return arbitrary objects from a constructor. We need the concept of construction. It's unique; it means "build a brand new instance." You can't replace it with a higher-level factory abstraction. Any factory abstraction would have to delegate back to construction at some point so the factory abstraction itself wouldn't be called "construction."

[DavidArno]

@jnm2,

I don't understand why you'd ever expect to be able to return arbitrary objects from a constructor.

I'm not sure we would expect to. new is just a built-in factory. But other factories are needed too, thus the various factory patterns. Language syntax for replacing those patterns would be nice. But it really isn't a priority in my view.

[iam3yal]

#164 should solve this problem.