Do not require type specification for constructors when the type is known

[paulomorgado]

Do not require type specification for constructors when the type is known.

Imagine this case:

Dictionary<string, List<int>> d = new Dictionary<string, List<int>>();

becomes:

Dictionary<string, List<int>> d = new();

Obviously, constructor arguments and object initialization would be allowed.

This might be a simple optimization given the above example, but there are longer type specifications out there.

But when applied to this:

XmlReader.Create(reader, new XmlReaderSettings{ IgnoreWhitespace = true });

it would become this:

XmlReader.Create(reader, new{ IgnoreWhitespace = true });

which is a lot more readable. In cases like this, the type is not really important, its properties are.

[FlorianRappl]

How is this readable? I see people complaining that

var d = new Dictionary<string, List<int>>();

is not readable (which I can't understand at all, as the full information is on the line -- it just avoids duplication). So the provided one wouldn't satisfy these guys, I guess.

But okay, now to your second point: If I just omit the possibility of having overloads (and how that should be handled) then I don't see how this is more readable at all. First it looks like an anonymous class instance, which is a false friend (and how this ambiguity should be handled is also unclear). Second, even if some constructor is used, we need to know the available method signatures for knowing which constructor to call. Therefore no one can read the code just from that one line.

So what are my doubts?

• Overload resolution
• Readability (especially in combination with method calls)
• Clash with anonymous objects

[thomaslevesque]

I don't like the fact that it clashes with anonymous objects. In the case you show with XmlReaderSettings, there is no ambiguity, but what about this?

void Foo(Bar bar);
void Foo<T>(T arg);

class Bar { public int X { get; set; } }

If I write Foo(new { X = 42 }), am I calling Foo(Bar) or Foo<T>(T)?

[dsaf]

It seems that people want (this and other inference discussions) elements of Hindley-Milner, but not the total way it was implemented in F#.

[paulomorgado]

@FlorianRappl,

This is not intended to please the ones that don't like var d = new Dictionary<string, List<int>>();. They'll probably like this even less:

Dictionary<string, List<int>> d;
...
d = new();

I don't expect the compiler to read the developer's mind or beyond that.

This would only be possible if the type of the variable/parameter/field has a publicly accessible constructor with that signature.

This wouldn't be possible:

IDictionary<string, List<int>> d = new();

Overload resolution would be a bit harder but not impossible.

As for readability, I don't think it's worth than other cases we already have.

@thomaslevesque,

How would that work for Foo(new Bar{ X = 42 })? It would be a call to void Foo(Bar bar), right?

T in void Foo<T>(T arg) is not a type, it's a type parameter. There are two implementation decisions that can be made here. Either the compiler doesn't try to bind to void Foo<T>(T arg), because it's missing information to do so, and just tries to bind to void Foo(Bar bar); or it doesn't try at all.

@dsaf, I don't know. It would be inferring the type of the parameter from the method definition. Not inferring the return type of anything.

[svick]

@paulomorgado

T in void Foo<T>(T arg) is not a type, it's a type parameter. There are two implementation decisions that can be made here. Either the compiler doesn't try to bind to void Foo<T>(T arg), because it's missing information to do so, and just tries to bind to void Foo(Bar bar); or it doesn't try at all.

So you're saying that Foo(new { X = 42 }) would either call the Bar overload or it wouldn't compile? Because both would be a breaking change, the code currently compiles and calls the T overload.

[thomaslevesque]

How would that work for Foo(new Bar{ X = 42 })? It would be a call to void Foo(Bar bar), right?

Yes, but in this case you explicitly specify the type, so it's obvious you want to call the one that takes a Bar. But if you use Foo(new { X = 42 }), with your proposal both methods are valid candidates, when currently only the generic one is valid. This adds another case where the compiler must either fail with an ambiguous match error, or make a decision that might not be obvious to the developer.

T in void Foo(T arg) is not a type, it's a type parameter. There are two implementation decisions that can be made here. Either the compiler doesn't try to bind to void Foo(T arg), because it's missing information to do so, and just tries to bind to void Foo(Bar bar); or it doesn't try at all.

But currently the compiler does bind to Foo<T>(T arg) if you pass an anonymous type... If you change that, you break a lot of existing code.

[paulomorgado]

Oops! Missed that one. I don' think we can get around that one.

Even if we could come up with an alternative to anonymous types (new ?{ X = 42 }) that would still be a breaking change.

Something like new !{ X = 42 } to indicate a non anonymous type would look ridiculous.