<p>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 &lt;> "" and table.a &lt;> NULL would return two separate results.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2012-05-04T15:24:25.127Z
The strings are not just plain old objects.  The CLR module format uses constant pools containing strings (like Java class files) to define method and property names for classes.  Thus the language has an intrinsic string type that is prior to the definition of classes including that of the base class.
Mike Samuel
CC BY-SA 3.0
2012-05-04T15:29:07.333Z
The reason for NULL in the CLR is not interoperability with SQL, but interoperability with COM and OLE which are two object models used extensively by Windows and the foundation classes (MFC).  Both of these used NULL as a possible return value for pointer types because of Window's C/VC++ heritage.  NULL in CLR == NULL in VC++ == NULL in C.  NULL in CLR != NULL in SQL.
Mike Samuel
CC BY-SA 3.0
2012-05-04T15:29:40.417Z
MSDN says: "The string type represents a string of Unicode characters. string is an alias for System.String in the .NET Framework."
user148298
CC BY-SA 3.0
2012-05-04T15:44:26.957Z
That's probably fuzzy language, .NET strings are sequences of UTF-16 code-units, not code-points.  The use of intrinsic strings and blobs in object metadata is described in the [CLR docs](http://msdn.microsoft.com/en-us/library/8dkk3ek4(v=vs.71).aspx) thus: "Metadata also stores information in four heap structures: string, blob, user string, and GUID. All the strings used to name types and members are stored in the string heap. For example, a method table does not directly store the name of a particular method, but points to the method's name stored in the string heap."
Mike Samuel
CC BY-SA 3.0
2012-05-04T16:01:12.140Z
Getting back to NULL, I was talking about intrinsic types vs POCOs.  POCOs have always been nullable, but nullable intrinsic types were introduced with .NET 2.0. MSDN says that they were introduced to make it simpler to persist uninitialized variables (SQL and XML serialization).  Support for COM has always been a part of the CLR since .NET 1.0.
user148298
CC BY-SA 3.0
2012-05-04T17:31:02.503Z
W.r.t. other language specifications, I've understood "intrinsic" to mean "defined in the language specification, not in library code" but you seem to be using it differently.  What is your definition?  Does it correspond to "value"/"selfless" types -- one where equality compares structurally instead of by comparing references?
Mike Samuel
CC BY-SA 3.0
2012-04-10T02:12:27.013Z
2012-04-10T02:39:19.507Z
2012-04-10T02:39:19.507Z
user148298
<p>Strings are object variables, unlike the atomic types supported for performance reasons.</p>

<p>For orthoginality it is easier if they are implemented in the same way as any other object and permitted to have a null value.</p>

<p>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.</p>

CC BY-SA 3.0
2012-04-10T02:23:37.263Z
If I have three strings with the same value "Hello World!" and I change one of them it would change all three or would it create a new storage for the one I changed?  If it does, then the CLR has a really impressive memory manager.
user148298
CC BY-SA 3.0
2012-04-10T09:41:23.477Z
.NET strings are immutable, so you can't change them.  Whether or not three strings with the same value are the same object or not depends on the details of string interning, which are set by the programmer at program startup.
Neel Krishnaswami
CC BY-SA 3.0
2012-04-09T23:10:55.693Z
2012-04-09T23:10:55.693Z
Pekka
<p>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 <code>option</code> or Haskell <code>Maybe</code> (paired with sane deconcstructors for such types that force the programmer to always consider both possibilities).</p>

<p>The main reason for this is that null pointers, null objects, and the like are responsible for many, many bugs and countless headaches.</p>

CC BY-SA 3.0
2012-04-15T14:46:11.850Z
I should try getting 10 upvotes for such a comment on reddit... that would be a real challenge.
Andrej Bauer
CC BY-SA 3.0
2012-05-07T01:01:24.773Z
“null pointers, null objects, and the like are responsible for many, many bugs and countless headaches.”  Is there any study showing this rigorously?  I do not like nullable object types either, but I find it hard to back up the claims like this by facts.
Tsuyoshi Ito
CC BY-SA 3.0
2012-04-10T07:08:32.833Z
2012-04-10T07:08:32.833Z
Andrej Bauer
<p>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?</p>

CC BY-SA 3.0
2012-04-10T20:25:26.300Z
It's a [billion dollar mistake](http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake) that stuck.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2012-04-11T01:11:51.310Z
Familiarity.  The other choice would have forced programmers to deal with issues that (in C and Java) they are not forced to deal with.  Too much unfamiliarity might have killed C# as a competitor for Java.  In other words, it was a `marketing' decision, not a technical one.
Jacques Carette
CC BY-SA 3.0
2012-05-07T01:14:10.763Z
Many people agree that implicitly nullable types are evil, and I understand that opinion.  But I find it hard to turn such arguments into more than a personal taste and a poll.  For example, in many languages, functions are allowed to have side effects.  Pure functional programmers may say, “Implicit side effects are evil.  Side effects should be made explicit in types.”  I do not necessarily agree with this, although I still think that implicitly nullable types are evil.  I am not sure what the difference is.
Tsuyoshi Ito
<pl.programming-languages>
What advantages does having a null-able string type confer to a programming language?
blueberryfields
# What advantages does having a null-able string type confer to a programming language?

(Asked by: username_0 on 2012-04-09)

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?

**Tags:** pl.programming-languages

> **Comments:**
> **username_1**: It's a [billion dollar mistake](http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake) that stuck.  
> **username_2**: Familiarity.  The other choice would have forced programmers to deal with issues that (in C and Java) they are not forced to deal with.  Too much unfamiliarity might have killed C# as a competitor for Java.  In other words, it was a `marketing' decision, not a technical one.  
> **username_3**: Many people agree that implicitly nullable types are evil, and I understand that opinion.  But I find it hard to turn such arguments into more than a personal taste and a poll.  For example, in many languages, functions are allowed to have side effects.  Pure functional programmers may say, “Implicit side effects are evil.  Side effects should be made explicit in types.”  I do not necessarily agree with this, although I still think that implicitly nullable types are evil.  I am not sure what the difference is.  

---

## 3 answers

### Answer by username_8 on 2012-04-10. Score: 13 | Accepted answer

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.

> **Comments:**
> **username_8**: I should try getting 10 upvotes for such a comment on reddit... that would be a real challenge.  
> **username_3**: “null pointers, null objects, and the like are responsible for many, many bugs and countless headaches.”  Is there any study showing this rigorously?  I do not like nullable object types either, but I find it hard to back up the claims like this by facts.  

---

### Answer by username_4 on 2012-04-10. Score: 5

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.

> **Comments:**
> **username_5**: The strings are not just plain old objects.  The CLR module format uses constant pools containing strings (like Java class files) to define method and property names for classes.  Thus the language has an intrinsic string type that is prior to the definition of classes including that of the base class.  
> **username_5**: The reason for NULL in the CLR is not interoperability with SQL, but interoperability with COM and OLE which are two object models used extensively by Windows and the foundation classes (MFC).  Both of these used NULL as a possible return value for pointer types because of Window's C/VC++ heritage.  NULL in CLR == NULL in VC++ == NULL in C.  NULL in CLR != NULL in SQL.  
> **username_4**: MSDN says: "The string type represents a string of Unicode characters. string is an alias for System.String in the .NET Framework."  
> **username_5**: That's probably fuzzy language, .NET strings are sequences of UTF-16 code-units, not code-points.  The use of intrinsic strings and blobs in object metadata is described in the [CLR docs](http://msdn.microsoft.com/en-us/library/8dkk3ek4(v=vs.71).aspx) thus: "Metadata also stores information in four heap structures: string, blob, user string, and GUID. All the strings used to name types and members are stored in the string heap. For example, a method table does not directly store the name of a particular method, but points to the method's name stored in the string heap."  
> **username_4**: Getting back to NULL, I was talking about intrinsic types vs POCOs.  POCOs have always been nullable, but nullable intrinsic types were introduced with .NET 2.0. MSDN says that they were introduced to make it simpler to persist uninitialized variables (SQL and XML serialization).  Support for COM has always been a part of the CLR since .NET 1.0.  
> **username_5**: W.r.t. other language specifications, I've understood "intrinsic" to mean "defined in the language specification, not in library code" but you seem to be using it differently.  What is your definition?  Does it correspond to "value"/"selfless" types -- one where equality compares structurally instead of by comparing references?  

---

### Answer by username_6 on 2012-04-09. Score: 1

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.

> **Comments:**
> **username_4**: If I have three strings with the same value "Hello World!" and I change one of them it would change all three or would it create a new storage for the one I changed?  If it does, then the CLR has a really impressive memory manager.  
> **username_7**: .NET strings are immutable, so you can't change them.  Whether or not three strings with the same value are the same object or not depends on the details of string interning, which are set by the programmer at program startup.  

---

