Restore requirement for struct constructors to always have formal parameters. #1029

Closed
VSadov opened this Issue Mar 4, 2015 · 1 comment

Projects

None yet

5 participants

@VSadov
Member
VSadov commented Mar 4, 2015

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.

@VSadov VSadov self-assigned this Mar 4, 2015
@gafter gafter added this to the 1.0 (stable) milestone Mar 4, 2015
@VSadov VSadov modified the milestone: 1.0-rc2, 1.0 (stable) Mar 4, 2015
@VSadov VSadov added a commit to VSadov/roslyn that referenced this issue Mar 5, 2015
@VSadov VSadov Restored requirement for struct constructors to always have formal pa…
…rameters (C#)

Issue #1029

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.

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.
7bff65a
@default0
default0 commented Mar 6, 2015

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.

@VSadov VSadov added a commit to VSadov/roslyn that referenced this issue Mar 6, 2015
@VSadov VSadov Restored requirement for struct constructors to always have formal pa…
…rameters

Fixes #1029

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.

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.
1a6b2f0
@VSadov VSadov closed this in #1106 Mar 6, 2015
@gafter gafter assigned gafter and unassigned VSadov Mar 9, 2015
@gafter gafter added the Verified label Mar 9, 2015
@theoy theoy added the Enhancement label Mar 19, 2015
@gafter gafter was unassigned by jaredpar Nov 23, 2015
@jaredpar jaredpar removed this from the 1.0-rc2 milestone Nov 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment