Implicit Interface casts of Nullables

Question

With VB's Option Strict On, why does a Nullable(Of T) not require an explicit cast to an interface of T when it does require one to T?

I.e.

Dim x As Integer? = 5
Dim y As Integer
Dim z As IComparable

y = x ' Fails to compile with error
      ' "Option Strict On disallows implicit conversions from 'Integer?' to 'Integer'."
z = x ' Succeeds

EDIT: As (sort of) shown by @SSS, part of the answer is that Nullable values are, well, nullable, and can be Nothing, which is fine for a reference like an interface. So this conversion will always succeed, unlike the conversion to T case (which fails when the Nullable has no value), and so it can be seen as an implicit conversion.

My question now becomes "how?". How is the conversion from a Nullable(Of T) (which has no interfaces of its own) to an interface of T theoretically negotiated?

I know the implementation is box Nullable<T>, which effectively strips the Nullable wrapper, but I'm confirming the concept here...

(So I'll review the documentation and see if they explain this.)

Answer 1

I don't see the problem?

y = x 

can fail because x could hold a value of Nothing, but y is not allowed to hold a value of Nothing. The IComparable interface allows Integers to be compared to Nothing however, so that assignment is fine.

Notice that if you swap it round:

x = y

then this succeeds because every value of y can be assigned to x.

You can confirm that Integers can be compared to Nothing as follows:

MsgBox(5.CompareTo(Nothing))

Answer 2

From what I can tell in vb.net, the statement interfaceVariable = nullableVariable is essentially equivalent to interfaceVariable = if(nullableVariable.HasValue, CType(nullableVariable.Value, interfaceType), Nothing). The C# compiler seems to handle things the same way: interfaceVariable = nullableVariable; becomes interfaceVariable = nullableVariable.HasValue ? (interfaceType)nullableVariable.Value : null;.

If the type of nullableValue.Value implements the interface, then nullableVariable.Value will either perform return a value-type result or throw an exception. Since there exists a guaranteed boxing conversion from the return value to the interface, the cast will be legal. The only way the above code could fail would be if the nullable variable gets written between the calls to HasValue and Value, such HasValue sees the variable as non-null, but Value sees it as null and throws an exception. I believe that writing interfaceVariable = nullableVariable just tests nullity once, so that an exception could not occur; instead, an indeterminate value would get boxed.

Answer 3

Without actually reading documentation yet, I'm going to attempt an answer:

Firstly, the higher-level answer is that casting a Nullable to an interface is "safe" and will not throw, so it is logically a Widening operator and should not need to be explicit (compared to casting to T, when .HasValue is False it throws, so it should not be implicit with Option Strict On).

However, technically the "how" is a bit obscure: Even though some of the behaviour of Nullable is encoded in the metadata available via reflection, much of its "magic" is hidden in:

• the runtime behaviour of box on a Nullable (and thus the compiler knows when to leave "lifting" to that), and
• the other points made by Eric Lippert in his answer for C# and their equivalent in VB.NET.

It looks like S. Somasegar's blog post announcing changes to Nullable support in a late beta release for VS2k5 is also relevant here.