Collection expressions vs readonly

[fandrei]

The following code works:
1.

	class Test
	{
		public readonly List<int> List = [];
	}

	static readonly Test Obj = new()
	{
		List = { 0 },
	};

and this code works too:
2.

	static readonly List<int> Vals = [0];

However, this code doesn't compile:
3.

	static readonly Test Obj1 = new()
	{
		List = [0],
	};

Shouldn't it work in this case, too?

[CyrusNajmabadi]

Shouldn't it work in this case, too?

No. The list is readonly, so it cannot be assigned.

To your examples:

	static readonly Test Obj = new()
	{
		List = { 0 },
	};

This is not an assignment of hte list. This is translated to:

Test __test = new Test();
__test.List.Add(0);
Obj = __test;

This is fine as the list is not assigned to, it just has a value added to it.

	static readonly List<int> Vals = [0];

This is the initializer of a readonly field, which is always legal. A readonly field can always be initialized with an iniitalizer, or by an assignment in the constructor of the type owning the readonly field.

[fandrei]

@jnm2 what about int[] vals = { 0 }? PS I see that you wrote about that already. So, sometimes it does that.

[CyrusNajmabadi]

In an object initializer, {} never allocates. This includes for arrays. It's always .Add. You'll note you cannot use = { ... } to initialize an array in an object initializer.

[jnm2]

You can think of that as special syntax, maybe even as legacy syntax, but it doesn't really come into the question about object initializers. We still have { CollectionMember = { a, b, c } } and { CollectionMember = new List<int> { a, b, c } }, which differ in meaning in a very important way: are you appending a, b, and c to an existing collection, or creating and assigning a new collection?

And { CollectionMember = [a, b, c] } already means one, and not the other. It can't mean both at once, and like Fred said, having it switch between meanings (append versus replace) based on distant code is highly unpalatable.

[fandrei]

In an object initializer, {} never allocates

I see. But in field and local variable initializers, it does. Special cases == more confusion.

[CyrusNajmabadi]

That decision was made in c# 3.0, almost 20 years ago. It's just something we'll have to live with because we cannot change it (for all teh reasons it would break that we've given above).

[CyrusNajmabadi]

Note: this is unrelated to collection expression. The following are illegal as well:

	static readonly Test Obj1 = new()
	{
		List = new(),
	};

	static readonly Test Obj1 = new()
	{
		List = new List<int>(),
	};

	static readonly Test Obj1 = new()
	{
		List = null,
	};

	static readonly Test Obj1 = new()
	{
		List = someOtherList,
	};

All of these are illegal, not because a collection expr was used, but because the field is readonly. You cannot assign it outside of hte field-initializer/constructor.

[CyrusNajmabadi]

= [] is not 20 years old, it's very new. I'd estimate this probability as less than 100 cases worldwide.

It would instantly break everyone who had done:

public record Anything(ImmutableArray<string> Values);

new Anything { Values = ["a", "b", "c"] }

This would now try adding to a non-initialized ImmutableArray, immediately throwing. This would also be the case for every other collection type. List<string> would throw as well, as calling .Add on null would break.

Every single consumer of collection expressions that intend to assign/initialize a value would now break.

We are not makign this change. Especially as it makes object-initializers less consistent with behavior around initialization or assignment of a property.

[CyrusNajmabadi]

Cases that immediately break if you move to = [...] calling 'Add' instead of assigning:

class C
{
    ImmutableArray<string> Values { get; set }
}

new C()
{
    Values = ["a"]; // this not throws, calling .Add on a 'default' immutable array.
}

or:

class C
{
    ImmutableArray<string> Values { get; set }  = ImmutableArray<string>.Empty;
}

new C()
{
    Values = ["a"]; // this now adds *nothing*, since calling .Add on ImmutableArray doesn't mutate the value.
}

Both of the above cases are legal C# today that works exactly how anyone would expect. You get a new C instance whose 'Values' property is an array with a single element with it. With your change both break. one breaks by throwing, the other breaks by losing values.

This pattern does exist, and it's certainly more than 100 cases worldwide.

[fandrei]

This pattern does exist, and it's certainly more than 100 cases worldwide.

I'm sure that it's not 20 years of code as you wrote before. This code wasn't even possible until very recently.

[CyrusNajmabadi]

This code wasn't even possible until very recently.

And yet it has distinct and specific meanings, that code will depend on. As shown above, if you change this meaning, you will break even trivial use cases.

[CyrusNajmabadi]

I'm sure that it's not 20 years of code as you wrote before.

This was in reference to the expectations around how object initializers work and the dependencies people have on it. Changing anything there is likely to break code. Even if we limit this just to collection expressions, it is still definitely breaking as even basic cases like the above which absolutely do exist will now break.

Breaking that code is not acceptable. The meaning it has is:

a. what we want
b. what the ecosystem wants
c. what real world programs absolutely depend on

We will not break this. It would be harmful.