Restore requirement for struct constructors to always have formal parameters.

[VSadov]

It has been a long standing requirement that C# and VB struct constructors would always have parameters. We have tried to relax this requirements in C#6.0 to make structs more consistent with classes.

While overall parameterless constructors in structs are valid from IL perspective, without a convenient way to declare them they were virtually nonexistent. As we performed more and more testing, we kept discovering cases where parameterless struct constructors caused inconsistent behavior in libraries or even in some versions of CLR.

A good example is the issue reported in the CodePlex bug http://roslyn.codeplex.com/workitem/465 .
The issue is basically an optimization introduced in Activator.CreateInstance around CLR 4.0 and present ever since. The optimization assumes that parameterless instantiation of generic T type does not cause sideeffects if T is found to be a struct and therefore instances can be cached. Parameterless struct constructors would violate such assumptions and make optimization observable, thus necessitating servicing of existing code several versions back.

After reconsidering the potential issues arising from breaking long standing assumptions, we decided it was best for our users to restore the requirement on struct constructors to always have formal parameters.

[default0]

I agree with the reasoning for restoring this requirement.
However, the optimization in Activator.CreateInstance is invalid independent of this constraint. Due to the nature of interoperability of IL-based languages, it is still possible for some other (maybe even 3rd-party) IL-based language to allow a construct like this, and have good reasoning behind why they want to do it.
The CLR should be designed with this in mind, not the languages around the optimizations that the CLR-developers want to do.
It's too late to reverse this decision, though, so restoring the requirement is the best option going forward.