Recently I tried to create a generic subclass by implementing a generic interface.
public interface IModule where T : DataBean { ..... }
public class Mo
I can't come up with any reason that the c# couldn't theoretically copy over constraints. But the documented behavior of making us copy (or augment) them explicitly seems to be the simplest way for usability.
public class A{}
public class B : A {}
public class X where T: A {}
public class Y : X where T: B { }
In the above, note that I did not have to explicty copy over the constraint on Y
, because a B
is always an A
.
Now lets look at what happens if the "compiler automatically copies over constraints". Let's say I define Y
without constraints and the compiler places them automatically. I use Y
in lots of code. Then I change the constraints on the declaration of X
to include some new interface.
The compiler errors for changing the declaration of X
are at the sites where I use Y
!
With the way the c# compiler currently works, the compiler errors are at the usages of X
, as I would expect if I change it in a breaking way.
So while it would be convenient in some scenarios, it would also be somewhat confusing in others. While both are valid approaches, I would assume (note that I'm not able to read the minds of the c# design team) that it was a judgement call and not a purely technical one.
I say "not purely technical", but I can certainly imagine some interface scenarios where it would be somewhat simpler to verify that all constraints are met, rather than produce the simplest constraint that meets all required inherited constraints.