Consistency of returned Strings [Kit George]

Atif Aziz asked this very interesting (and difficult) question regarding the behavior of strings:

It would be nice to see a single and consistent policy across the framework with respect to returning strings. Presently, one has to constantly look up the documentation to figure out if a given method considers all three states differently or not. In many cases, the documentation is even silent or vague about it. Consequently, one always ends up resorting to writing defensive utility functions that check if a string is null or empty where the difference is irrelevant. Such simple things really make life and code unnecessarily complicated. With the addition of Nullable<T>, things could even [get] stranger as one could then imagine four possible states! The fact that a string can be null is just an side-effect of having System.String being a reference type when in reality it is designed with semantics of a value type (i.e. immutable). What are your short-term and long-term plans to address this?With Nullable<T>, it would even make no sense for a function to return a null string. If a function might return null, then it should be clear from its signature.

Aziz, we can't change existing APIs (due to breaking change rules), which means the bird has flown on this one a little bit. We could consider requesting that all future APIs that return a string operate the same way, however the issue is very complex, and there is feeling here that there's no sensible default behavior which makes clear sense. Sometimes returning a null is useful, sometimes not: sometimes an empty string makes sense, sometimes it doesn't. You simply have to know about the specific API in question to be able to interpret the value it returns.

However, we absolutely must ensure that a guideline for Nullable<T> is available, and we have taken that issue to heart. Please keep an eye on the <a href=“https://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp“>Design Guidelines</a> for this guideline in the future.