You might have already read
this: VS2005 made the last-minute DCR related to boxed Nullable<T>.
Runtime now treats Nullable<T> differently from other generic value types
Reflection late-bind invocation always deals with "object"; value type instances
are always getting boxed first before invocation. One of such APIs: PropertyInfo.SetValue(Object
obj, Object value, Object
index). There was
one question in Microsoft Technical Forums: Exception is thrown when setting
DateTime value to a property with type Nullable<DateTime>. With this DCR change,
such late-bind calls can be written in a more natural way.
After boxing, 100 and (Int32?)100 are the same thing: boxed Int32 object. There
is no more boxed object with type "Int32?"; late-invocation has to accept it and
set to Int32? property. Or think it this way, runtime can not tell where a boxed
Int32 object was originally from: either just Int32 instance or Int32? instance;
it is reasonable to allow setting a boxed Int32 object to field/property of either
Int32 or Int32? type (same for argument pass-in when doing method invocation)
This actually worked before the DCR. And ,
ret will be either boxed Int32 object or simply null. There is no problem in casting
the result to Int32? type.
Here are some reflection behavior changes as a result of this DCR: