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=““>Design Guidelines</a> for this guideline in the future.

Comments (3)

  1. Anonymous says:

    The BCL team did listen to us to provide a little help here. It looks like we at least get a System.String.IsNullOrEmpty() method which will make the test for invalid string states a little simpler. It will also make source code using this method a bit more readable IMO.

  2. Anonymous says:

    Just in case you’re wondering, look out for the method Keith is referring to, in upcoming Whidbey betas…

  3. Anonymous says:

    Kit, I am aware that some things cannot be changed due to backward compatibility issues and that we have to sometimes bite the bullet and move forward. However, I think that the problem at hand can perhaps be solved in an interesting way at a much lower level with a little bit of help from CLR and compilers if not the BCL. Basically, if we think about it, System.String.IsNullOrEmpty() is the caller’s decision to ignore the distinction between null or zero-length (good or bad, we’ll all have to pretty soon sprinkle our code all over with this function). So wouldn’t it be possible to introduce a superficial string data type that can be guaranteed to never evaluate to null? It would be superficial because the magic of the illusion would be provided by either the language via the IL it produces or by the CLR via the code jitted at runtime. So I want the technology to work harder for me (by calling System.String.IsNullOrEmpty() on my behalf) and I want to express my intension simply (via a superficial string type). Managed world, remember? 😉 BTW, a living example of what I am hinting here can be seen in VB.NET today! See System.Runtime.CompilerServices.RuntimeHelpers.GetObjectValue(), which is a function that VB.NET call on my behalf and sprinkles in the IL it produces. It would be nice if something similar can be sought out for the 3-state strings in C# and VB.NET. What are your thoughts on this?

Skip to main content