Should we optimize or deprecate string.Empty in C#?

[tats-u]

There are 2 representation for an empty string in C#, "" and string.Empty.
Both finally refer to the same single string instance after compiled by JIT, but string.Empty is less optimized than "" in some context by Roslyn because it is just a static field.

// const string DefaultSomeValue = string.Empty; // error
const string DefaultSomeValue = ""; // OK

string someValue = "" + "foo " + "bar"; // Compiled to "foo bar" by Roslyn
string someValue2 = string.Empty + "foo " + "bar"; // Compiled to string.Concat(string.Empty, "foo bar") by Roslyn

Should we allow string.Empty to be converted to "" if heavier optimization is available, or deprecate it?

System.String.Empty is not registered in WellKnownTypes in Roslyn as of now.

[CyrusNajmabadi]

Why do we need to optimize this? What's the benefit obtained? Why not just meet the runtime optimize this?

[tats-u]

If C# recommended string.Empty more, it would have to be at least as fast as "" (dispel speed concerns completely), wouldn't it?
If it doesn't more, we don't have to optimize it more (leaving it as is, which you claim) is sufficient.
Is it true C#/.NET team officially doesn't recommend either of two more strongly (= recommend both in equal measure)?
The runtime is not only the cutting-edge .NET but matured .NET Framework, which has much longer support term, especially for desktop applications, or Mono.
Also, have we really asked BCLs to assure string.Empty is equals to "" in some specifications? I searched the string Empty in PDFs of ECMA-334/335, but I found they don't mention string.Empty.
If we allowed BCLs to set non-empty string to string.Empty, I think we should deprecate string.Empty.

[CyrusNajmabadi]

wouldn't it?

I don't see why that's the case, no. What's the tangible benefit to this? We have effectively infinite work and things that can be focused on. We should do things because of the real benefits they bring, otherwise, we're taking away time from much more beneficial things.

Is it true C#/.NET team officially doesn't recommend either of two more strongly (= recommend both in equal measure)?

I don't think we care on the C# team. Use whichever you think is best in your code.

The runtime is not only the cutting-edge .NET but matured .NET Framework,

We're not making optimization decisions based on .NetFx. If you want optimized, use .Net Core (which is often multiple times faster). .NetFx is legacy now, is not something we are doing work around, and prioritizes stability practically above all else (except perhaps security).

I think we should deprecate string.Empty.

That's a convo for the runtime team. But my guess is that no one is going to do any of that. This is a case of "if it's not broken, don't fix it". You're proposing touching parts of the system that could impact every project out there, and no actual real world info has been given to justify things.

[tats-u]

What's the tangible benefit to this?

In the application as a whole it's only margin of error. Comparing to LINQ, which is slower than foreach, string.Empty is clearer for non-programmers but longer than "", which It's common knowledge among almost all programming languages that represents an empty string.
It confuses beginners that C#/VB has two ways of expressing the empty string.
Some of those who teach C#/VB misunderstand that string.Empty were faster because it referes to a single instance but "" weren't be interned.
This is not tangible but "as fast as" and "slightly slower than" have different impressions.

I don't think we care on the C# team. Use whichever you think is best in your code.

So from the compiler's point of view there's no comment on that. Thank you.

We're not making optimization decisions based on .NetFx.

.NET Fx just gets a tiny share of the optimization for .NET Core.

no actual real world info has been given to justify things.

I know performance difference is margin of error, but it has confused many people for as long as about twenty years and is easily rewritten. That's all.