I think that's basically the only point of it. Since the beginning almost 20 years ago I have been using it. However I have also always questioned it, because other languages that I used, like C, Java and JS, don't have it. So the best thing to say is that it's helpful for readability, but in any other way not an actual need.

Yeah i've started using it aswell. Sometimes =""; looks like you missed something or it just don't look as clean as string.empty

@@jongeduard java, C, js can make empty string become EMPTY_STRING with module, class for constants intention and readability like C# :3

And he laments not being able to anymore. Man is clearly a war criminal.

You can change a lot of things if you use reflection, since it lets you touch private fields.

"" reuses one string object too. Constant (hard-coded) strings are interned by the compiler, which means that only one copy of them exists in memory at runtime. This is doable because strings are immutable - methods like ToUpperCase return a new string rather than modifying the existing one.

constants are evaluated at compile-time and directly replaced with their values wherever they are used in code. Therefore, if string.Empty were defined as a constant, every occurrence of string.Empty in the code would be replaced with an empty string during compilation. This means that any modification to the value of string.Empty in subsequent versions or updates of .NET would not be reflected in already compiled code, which could lead to unexpected behavior. By declaring string.Empty as a static readonly field, it allows for more flexibility and ensures that all references to string.Empty always point to the same empty string instance at runtime. This approach allows future updates to the .NET framework to modify the underlying implementation of string.Empty without breaking existing compiled code. Additionally, making string.Empty a static readonly field provides better performance compared to a constant, as the value doesn't need to be inlined during compilation. It also allows for lazy initialization, where the empty string object is created only when first accessed, reducing unnecessary memory allocation. Therefore, the decision to use static readonly for string.Empty in C# was made based on considerations of maintainability, flexibility, and performance...

Thanks ChatGPT ;-)

@@dongct2504 Why should the value of an empty string ever change in upcomming C# and/or .net versions?

c# only has isNullOrEmpty and IsNullOrWhiteSpace and they both work on a string set to "" as well as one set to string.Empty;

This comment is untrue, makes absolutely 0 sense if you know how string comparison works in C#, made up non existing methods in .net and even contradicted what was said in the video.

still got the same question

As a constant it would get inlined by the compiler, resulting in duplicate empty string objects - as a readonly static, everything has a reference to the same object. Same with Array.Empty etc: more efficient to share a single object than duplicates.

@@jas88cam No? String constants points to the same object in memory, this is a very bad response to the question.

@@diadetediotedio6918 the answer from one of the developers is basically that it's historical baggage in this case, and it is special-cased by the compiler rather than used as it appears. Back in Framework 3.5 and earlier, string.Empty apparently wasn't interned, but that changed later.

@@jas88cam Hm, can you say for me the name of the source you found this? (as youtube does not allow for URL's directly) I find this very strange, since as I know back in 3.5 < raw strings were also shared at runtime by the compiler. In fact, after testing it see: ``` Hello, World! And reference equality between 'a' and 'b' is: True ``` I used simple and raw empty ("") strings in the test project, and they shared the same reference. This is a project in .NET Framework 2.0, so I don't think the problem was in fact "duplicating string objects". What was the special casing they did with the string.Empty that did make it special?

It's the same thing but you might need to use the constant version in cases where fields are not acceptable like switches or default method parameter values.

Spoken like a true JavaScript dev 😂

@@RigelOrionBeta Funny of you to say that, because I'm mainly a cpp dev :p