Has the C# spec (team? committee?) ever considered this object creation syntax?

Question

^{I've never posted a question of this nature before, so if it's not proper for SO, just don't hurt my feelings too bad and I'll delete it.}

In the interest of keeping everything I care about as close to the left margin as possible, I keep wishing I could write something like:

DataService1.DataEntities dataEntities = new(constructorArg1, ...)

I think another reason is I like the extra screen real estate I get by using var when the type is already present on the right side of the assignment, but my brain has too many years of looking for the type on the left side. Then again, being stuck in my ways isn't such a good reason to wish for a spec...

Answer 1

Has the C# design committee ever considered this object creation syntax?

Yes, we have. We considered it a couple years ago. As evidence of this claim, see the last paragraph of my article here:

http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx

The consensus of the design team was that this was a "nice to have" feature but not sufficiently compelling that it was worth the considerable cost of designing, implementing, testing, documenting and maintaining the feature.

I note also that the comments to the blog entry I linked to are very negative about the feature; it seemed like a lot of people found the syntax unattractive. That was also points against doing the feature.

However, the proposed syntax becomes particularly nice if you can combine it with other language features that promote the concise declaration of immutable types; if we do such a feature in a hypothetical future version of the language, then the syntax you propose becomes more compelling.

I note further that we in general resist features that require inference from "outside" to "inside"; we prefer that type information flow from the inside out. Consider for example this problem:

M(new(blah));

Suppose M has two overloads, one that takes a C, and one that takes a D. Is that "new C(blah)" or "new D(blah)"? It could be either. Now we have to analyze both! And if they both work then we have to figure out which is better.

It gets worse. Suppose you have

M(new(new(blah)));

where again M takes a C and a D, and C has two constructors that take an E or an F, and D has two constructors that take an G and an H. Which of:

M(new C(new E(blah)));
M(new C(new F(blah)));
M(new D(new G(blah)));
M(new D(new H(blah)));

is chosen, and why?

When you reason from outside to inside you quickly get into "combinatoric explosions" where the number of cases to analyze becomes O(cⁿ) in the depth of the nesting.

C# does reason in this manner for lambdas and that is one of the hardest parts of the compiler to make performant and correct, believe me. We're not eager to add a similar feature to constructors. If we were to add this syntax it would probably be limited to scenarios in which the type was unambiguously known by analyzing the left hand side of a variable declaration or assignment expression.

(As always, I note that Eric's musings about hypothetical future language features in unannounced and entirely fictional products that do not have schedules or budgets is for entertainment purposes only, and not to be construed as a promise of any particular future product with any particular feature set.)