Dictionary property initialization not following as other type

[harpalsingh1993]

Hi Team,

The dictionary behaves differently while we have declare and initialize directly vs as a property.

Ex. Suppose I have class and it has property Data
public class TestClass { public Dictionary<string, string> Data {get; set;} }

And If I use it Like this

var dict = new TestClass { Data = { {"dict1", "disct1"}, {"dict2", "disct2"}, {"dict3", "disct3"}, } };

The issue it doesn't show compile time error, instead it throws run time error System.NullReferenceException: Object reference not set to an instance of an object.

https://dotnetfiddle.net/0o2dPX

If I use the dictionary directly it shows me compile time error

Thanks,

[HaloFour]

This is the expected behavior. When using the collection initialization syntax in such a manner you are adding entries to an existing collection rather than creating a new one:

// adds to existing dictionary
var dict = new TestClass {
    Data = {  {"dict1", "disct1"}, {"dict2", "disct2"}, {"dict3", "disct3"}, }
};

// creates new dictionary
var dict = new TestClass {
    Data = new Dictionary<string, string> {  {"dict1", "disct1"}, {"dict2", "disct2"}, {"dict3", "disct3"}, }
};

This only works during initialization of a type, which is why you can't do:

var dict = new Dictionary<string, string>();
dict = { "test1", "test2" };

[harpalsingh1993]

Thanks for clarification. But as @colejohnson66 mentioned, yes its confusing, whatever we learnt "=" means assignment, and if its adding, maybe better to have like spread operator type (...). I have legacy application that takes much time to build and debug and I spent an hour to figure out this is issue( which is expected behavior).

[huoyaoyuan]

Just clarify that it's not limited to sub-collection initializer, but any sub-object initializer.

The solution for this is nullable reference type. You need either to provider an initial collection to the property ({ get; set; } = new List<T>(), or just { get; } = new List<T>()), or mark it as nullable, or mark it as required to force the caller to specify something new.

[umashankardotnet]

Thanks for clarification. But as @colejohnson66 mentioned, yes its confusing, whatever we learnt "=" means assignment, and if its adding, maybe better to have like spread operator type (...). I have legacy application that takes much time to build and debug and I spent an hour to figure out this is issue( which is expected behavior).

Agreed, from syntax point of view it's confusing

[huoyaoyuan]

You are confused with = {} and = new() {}. A new object is created only with new present. = {} always means modification of existing object.

[jnm2]

And, = [...] always means creating a new object.

[huoyaoyuan]

The behavior is the same.

When used inside an object initializer CollectionProperty = { element } translate to CollectionProperty.Add(element), without calling constructor. The syntax can't be used out of object initializer.

It's consistent with other nested types:

class B
{
    public int Prop { get; set; }
}

class C
{
    public B Nested { get; set; }
}

var c = new C
{
    Nested = { Prop = 1 }
};

This also throws NullReferenceException because Nested is not initialized. Similarly, you can't write B b = { Prop = 1 } either.