Should C# add partial constructors?

Question

An answer in this question made me wonder about the .NET framework design choices.

The .NET framework has full support for Partial classes, interfaces, and methods. Is there a compelling reason that support for partial constructors was not added, in the same manner?

This seems like it would simplify class construction within partial classes. For example, form constructors built by a designer in Windows Forms could have the form construction code directly in the constructor, split into two files. Partial "Initialize()" methods seem to be a somewhat common pattern, which could be simplified in this case.

The only potential downside I can see would be the lack of determinism in the order of constructor calls, but in many cases, the ordering of the parts wouldn't matter. If it did, you could always avoid the partial constructor.

Answer 1

Well, partial classes and interfaces are another story. This concept would be comparable to partial methods. They actually does nothing but to tell the compiler this method can exist somewhere and if it doesn't remove the method call. It doesn't allow introduction of a duplicate method.

Since a constructor is never called directly, it wouldn't make any sense to have such a concept. I believe the current initialize pattern works pretty well in most scenarios. Introducing another partial thing would unnecessarily make the language more complex without introducing significant benefits.

Answer 2

I would vote no. Mainly because you can accomplish the same thing with a partial method that you are trying to accomplish with a partial constructor without the non-determanism issue.

Instead of having a partical constructor, have the WinForms designer run in the constructor. At the end of the generated code the emit a partial method and call to UserConstructor. Users could then use this for their initialization.

You could even do bookended partial methods to satisfy all scenarios (BeginUserConstructor and EndUserConstructor).

Answer 3

Partial methods don't allow for defining multiple parts of the function's body in two seperate locations. It merely allows for a signature to exist in one file, and the implementation to optionally exist in the other. If the body never gets defined, references to the method are removed by the compiler.

Like Mehrdad said...with the constructor, you never really need that kind of functionality so it was never implemented.

Answer 4

The only potential downside I can see would be the lack of determinism in the order of constructor calls, but in many cases, the ordering of the parts wouldn't matter. If it did, you could always avoid the partial constructor.

That part is more important to your question than it seems.

If you really want to understand how the C# language is put together, one thing you can do is follow Eric Lippert's blog. He works on the C# language for Microsoft, and talks a lot about choosing features with limited resources. Read his blog for a while and you'll start to get a sense of how features make it into the language.

One factor he's mentioned on a few occasions is whether or not there's already a trivial work-around for the problem the feature would solve. So going back to the quoted portion of your question, you bring up two important points:

1. There's no good solution to the lack of determinism. If you can offer an elegant solution as part of your post you'll have a better case.
2. There's a trivial work-around already.

Put those together and it's just not a winning feature.

Answer 5

I would vote yes, and I'll give a concrete example why.

Many technologies that emit code using a generator (Linq To SQL for example) will/must emit a default constructor. However, often I will also want to do things in a constructor, such as wiring up to one of the data events.

I can't do this without a partial constructor, since the default constructor is already tied up by the generated code, and I obviously don't want to alter the generated code to add my logic there.