Unexpected redundant reference during C# lowering

[dariomrk]

While experimenting with SharpLab to understand C# compiler optimizations, I observed an intriguing behavior during the lowering process of collection initializers. Specifically, initializing a HashSet<string> resulted in an additional reference assignment in the lowered code¹.

The input:

var foo = new HashSet<string>
{
    "Foo",
    "Foo",
};

gets converted to:

HashSet<string> hashSet = new HashSet<string>();
hashSet.Add("Foo");
hashSet.Add("Foo");
HashSet<string> hashSet2 = hashSet;

Complete SharpLab demo: here
Compiler version: main (19 Jan 2024)

The puzzling part: HashSet<string> hashSet2 = hashSet;.

• Is this reflective of the actual compiler output, or could it be an artifact of how SharpLab presents the lowering process?
• Could someone clarify the rationale behind creating this additional reference in the lowered code (given that this is actual compiler output)?

I've attempted to find related discussions or documentation on compiler design decisions that might explain this behavior but to no avail. I'm curious if this pattern serves a specific purpose?

Any insights or explanations would be greatly appreciated!

Footnotes

1. Behavior can be replicated with other classes. E.g. List<string> should also result in the described behavior. ↩

[CyrusNajmabadi]

This is by design. The language says that this assigns to a temp and then finally assigns the temp to the final location.

Is this reflective of the actual compiler output,

THis is the actual compiler output.

Could someone clarify the rationale behind creating this additional reference in the lowered code (given that this is actual compiler output)?

Sure. Imagine you had the following:

private HashSet<string> set;

void Initialize()
{
    set = new HashSet<string> { "a", "b", GetValue() };
}

string GetValue() => throw new NotImplementedException();

We do not want 'set' to be in an intermediate state just because GetValue() failed. We want it to be totally initialized, or not at all.

Similarly, we don't want any code that is executing to be able to look at 'set' and see it changing as that initializer runs.

So we create a temp, initialize it, and do a final assignment when it completes successfully.