title: Boxing / Unboxing Nullable Types - Why this implementation?
body: <p>Extract from CLR via C# on Boxing / Unboxing value types ...</p>
  
  <p>On Boxing: If the nullable instance is not <strong>null</strong>, the CLR takes the value out of the nullable instance and boxes it. In other words a <strong>Nullable &lt; Int32 ></strong> with a value of <strong>5</strong> is boxed into a <strong>boxed-Int32</strong> with a value of 5.</p>
  
  <p>On Unboxing: Unboxing is simply the act of obtaining a reference to the unboxed portion of a boxed object. The problem is that a boxed value type cannot be simply unboxed  into a nullable version of that value type because the boxed value doesn't have the <strong>boolean hasValue</strong> field in it. So, when unboxing a value type into a nullable version, the CLR must allocate a <strong>Nullable &lt; T ></strong> object, initialize the <strong>hasValue</strong> field to <strong>true</strong>, and set the <strong>value</strong> field to the same value that is in the boxed value type. This impacts your application performance (memory allocation during unboxing).</p>
  
  <p><strong>Why did the CLR team go through so much trouble for Nullable types  ? Why was it not simply boxed into a Nullable &lt; Int32 > in the first place ?</strong> </p>