I've been trying to understand the rationale behind the design of the C# language. Are there any specific advantages that can be gleaned from allowing string type variables to contain null?
At the risk of starting a religious war, I will express my opinion that there are no advantages to having nullable types. These should always be replaced by a sum type such as Ocaml
option or Haskell
Maybe (paired with sane deconcstructors for such types that force the programmer to always consider both possibilities).
The main reason for this is that null pointers, null objects, and the like are responsible for many, many bugs and countless headaches.
Since the .NET Framework is database oriented, it would stand to reason that the designers of the Common Runtime Languate introduced nullable types to mirror SQL values. A null value has special meaning in SQL and is perfectly valid. For instance, two queries with the clause WHERE table.a <> "" and table.a <> NULL would return two separate results.
Out of convenience and brevity, the CLR introduced nullable types to make it easier to translate values back and forth from SQL without extensive coding for intrinsic types such as int, float, etc. The nullable versions are int?, float?, etc.
Strings are intrinsic types in .NET, but they are really plain old objects under the hood. Consequently, there's no need for a string? type.
Strings are object variables, unlike the atomic types supported for performance reasons.
For orthoginality it is easier if they are implemented in the same way as any other object and permitted to have a null value.
In practice, strings are rather special and share storage across all instances. This provides the side effect that all string objects with the same value contain the same pointer making comparison trivial.