Why is "" not the same as string.Empty?

[jods4]

For the longest time (probably since C# 1.1 😄) I thought that "" and string.Empty were compiled identically by C#.

And I just noticed that it's not the case!
C# compiles them quite literally to ldstr and ldsfld.
Then the JIT performs some inlining magic but the result is still not quite the same:

• string.Empty is inlined into a constant mov eax, 0x9ef0004.
• "" involves one memory access mov eax, [0x5584684]

Ok this is a tiny difference that's probably never gonna be noticeable in a real life benchmark.
On the other hand this is a very low hanging fruit, so why not?

[CyrusNajmabadi]

This is not a language question. They're not hte same because they're not the same :) String.Empty is a field. So the compiler translates referneces to it to ldfld. Whereas "" is just a constant which gets ldstr.

[jods4]

@CyrusNajmabadi yes, that's obviously a legit answer.
At the same time, it's also omitting that the compiler often does things differently from code.

For example C# "a" + b + "c" is not translated into two + operator calls on string.
C# optimises to the well known string.Concat("a", b, "c") method instead.
This example has more assumptions on how these operators and methods work than what's in the readonly string.Empty field.

Where does the language team draw the line? Why is string.Concat an optimisation in the compiler but "" is "obviously" not something the compiler should entertain?

[CyrusNajmabadi]

Where does the language team draw the line?

This is not a language team question. :)

In terms of hte compiler, it must abide by the rules of hte language. For + their translation abides. For String.Empty and "" their impl abides.

but "" is "obviously" not something the compiler should entertain?

You have it reversed. No one said it should not be entertained. You're asking why it didn't happen. The likely answer is simply: because no one did it or cared about it.

[jods4]

because no one did it or cared about it.

I figured it would be the eventual answer 😆 . I was just curious, I don't know why I was convinced it was the case since early C# days.

Thanks.

[colejohnson66]

JIT optimization questions are for dotnet/runtime.

[HaloFour]

Use reflection to change the value of String.Empty and watch everything go 💥.

[KennethHoff]

IIRC that's not possible after .Net Core (or maybe even way earlier)

[jods4]

Yeah that was possible in .net fx but it was fixed in .net core. Nowadays reflection throws if you attempt to modify a readonly field.

And quite frankly, if you do this kind of things (hey why not mutate the interned empty string with unsafe code?), sure everything go 💥 what else do you expect? Plenty of libs and user code use string.Empty nothing would work regardless of C# compilation choices.

[koszeggy]

Nowadays reflection throws if you attempt to modify a readonly field.

Just for static fields. Otherwise, it would make little sense to use RuntimeHelpers.GetUninitializedObject(Type) (earlier: FormatterServices) for anything.

But actually this is just an extra check in FieldInfo.SetValue; the runtime still allows you to change static readonly fields.

[333fred]

The runtime can and will inline static readonly fields during tiered recompilation. Attempting to set static readonly fields will result in undefined behavior.