An interesting discussion around a particular Breaking Change: the verdict [Kit George]

Well, I wasn't prepared for the wealth of responses and I can tell you, we absolutely appreciate it. It's great to see a bit of passion around this kind of subject.

Result: we're going to say the change is acceptable.

We were already leaning towards the side which most of the respondees seemed to be on: allow this kind of change, but the wealth of opinion here certainly helped the argument.

Fundamentally, we agree with this respondent ('Me' on the 3rd of November), who said:

"Please don't ever make breaking changes. I don't want to spend the effort to deal with broken code, even if it was stupid in the first place."

The problem with this particular change is, we haven't thought of a reasonable scenario where someone actually IS broken by this change. If we could perceive one, we'd then have a really solid argument against this kind of change. But without that scenario, it's difficult to argue. An attempt at trying to identify a breaking scenario was nicely summed up by our own Joe Duffy later on the 3rd:

"I guess if someone were relying on the member being there, but not for purposes of ever calling it, it might be a problem. E.g. typeof(Test).GetConstructor(new Type[0]) would now be null, where it returned an instance previously. Seems the liklihood of this is rather low..."

Certainly, there was a recurring theme to the discussion, to consider making this situation (having a public .ctor on an abstract type) a compiler warning. Luc Cluitman's response on the the 4th can be used as an illustration:

"And I am also in favor of a compiler warning for it. I support Ben Monroe's view (above) in the 'what about newbies?' issue: "A class with a public constructor can be instantiated"."

This speaks to the fact that allowing this in the first place doesn't seem such a hot decision. Matt (thanks for your continued interest Matt) pointed this out, in his response to Joe White on the 4th:

"You just called the original implementers of the .NET framework stupid and nonsensical!"

Certainly, there's the odd thing that stands out as 'odd' in the framework, and this appears to be one of them. I have asked the compiler teams to look over this thread, and consider the merits of adding a compiler warning for this scenario. But until we have a solid case of reasonable broken code, it seems appropriate to allow the change here.

Once again, thanks for all the feedback: fantastic!

Kit