Constructor Contracts in interfaces

[StellarWolfEntertainment]

With the addition of static abstract methods for interfaces, I have been working with Ideas that I had previously not been able to (because interfaces couldn't define static methods at all), while I was working on these I noticed that there was a large number of times where I was working around what could have been a constructor, but instead had to be a factory method, for example in this interface (and yes in this specific instance I could instead use an abstract class, but that would constrain binary read/writable types to reference types only an interface does not)

public interface IBinary<T> where T : IBinary<T>
{
    static abstract T Read(BinaryReader reader); // this would function just fine as a constructor instead, there's no actual reason that this has to be a factory method, except that I can't define it as a constructor instead.
    void Write(BinaryWriter writer);
}

could instead be written like this

public interface IBinary<T> where T : IBinary<T>
{
    IBinary(BinaryReader reader);
    void Write(BinaryWriter writer);
}

the first example can be used something like this (pulled from the same project I defined the interface for, and is an extension method)

public static T Read<T>(this BinaryReader reader)  where T : IBinary<T>
{
    return T.Read(reader); // while there is nothing wrong with this idea, I think that the concept would be better served as a constructor.
}

and the second like so

public static T Read<T>(this BinaryReader reader)  where T : IBinary<T>
{
    return new T(reader); // this just feels cleaner, and is more descriptive about what is actually happening here
}

There are cases where I've defined an interface and a number of deriving types that all have matching constructors (or otherwise matching constructors, when generics are involved with the data) and then had to create factory methods to return such types, the constructor idea would allow for more extendible interface relationships, for example one might create an interface for an NN model that uses an empty constructor, but are entirely intended to be interchangeable, to solve the first part you could do this,

public interface INNComponent<T> where T : new(), INNComponent<T>
{
}

but then when requiring an INNComponent we have to specify the T portion, that doesn't really work for the interchangeable part of the problem, which could be solved with Constructor contracts like so

public interface INNComponent
{
    INNComponent();
}

because in this example INNComponent is not generic, we can simply request an INNComponent making it truly interchangeable.

[HaloFour]

See: #837

[StellarWolfEntertainment]

I hadn't found that one yet, and I see that there is overwhelming opinion about how telling a type that it must implement a constructor with a specified parameter list is 'bad programming', personally I disagree on that note, for a few reasons
A) it's not like the interface is the be all and end all of the implementing class, if the class requires other constructors, it is not restricted from that
B) thought perhaps the mention of the 'generic constraint' to define a constructor signature would be sufficient, the ability to properly 'name' the parameters of a required constructor would also be a beneficial feature