In my strong opinion, the only really valid answer will be: because creators of .NET decided to design it this way. (Did
Anders Hejlsberg made a decision?)
Not that I say that the decision is not good. It's quite good, at least good enough. I just say, that I am sure that some other reasonable decisions are possible, and it's not possible to say that one of them is absolutely the best. I am well familiar with variety of constructor rules in a number of object-oriented languages (including .NET and C# predecessor, Delphi; with architecture created when Anders Hejlsberg was a chief architect in Borland), and I can tell that some syntax and semantic rules are different and not as good as in .NET, but some are different and at least not worse than that of .NET.
In view of this, all the explanations found in many source, including those explained or referenced by Varun, are somewhat funny. First, they look reasonable. Some arguments emphasize the real value of the rules under discussion. The only problem is: they do not proof anything; they just illustrate the well known phenomenon: many people are very skilled to adjust reasoning to the know fact.
[EDIT]
I did not proof anything, but I need to illustrate that at least one argument is logically imperfect. Let's pick this one:
Varun Sareen wrote:
The .NET Common Language Runtime (CLR) does not guarantee that parameterless constructors will be called.
First, this statement is simply not correct. A class always have either implicit parameterless constructor unless an explicit constructor is defined. An explicit constructor is semantically equivalent to the constructor with empty body. In this way, it is semantically not important if it is called or not, but the whole chain of inherited constructors should be called anyway. As to the explicit parameterless constructor, it is guaranteed to be called.
In this way, the quoted statement is not true or makes no sense for class constructors. But does it make sense for parameterless
struct
constructors? No, because the syntax does not allow such constructors anyway.
Here is the example of circular "proof". The speculation goes: parameterless constructors are not allowed by the syntax, because if they were allowed, their call would not be guaranteed. But why the decision "not to guarantee a call the a parameterless
struct
constructors" would be made? This is a purely speculative consideration.
[END EDIT]
With all my respect to those authors really understanding software development: this is the phenomenon which explains the nature of superstition.
—SA