Anomaly when using 'var' and 'dynamic'

Question

I've run into a bit on an Anomaly where for the first time ever, using the var keyword bit me.

Take this very simple method

public static Int32? GetNullableInt32(Int32 num)
{
    return new Nullable<Int32>(num);
}

Now we can call this method with a dynamic parameter and everything will work as expected.

public static void WorksAsAdvertised()
{
    dynamic thisIsAnInt32 = 42;

    //Explicitly defined type (no problems)
    Int32? shouldBeNullableInt32 = GetNullableInt32(thisIsAnInt32);

    Console.Write(shouldBeNullableInt32.HasValue);
}

However, by declaring shouldBeNullableInt32 using implicit typing, the results are far from what I would expect.

public static void BlowsUpAtRuntime()
{
    dynamic thisIsAnInt32 = 42;

    //Now I'm a dynamic{int}... WTF!!!
    var shouldBeNullableInt32 = GetNullableInt32(thisIsAnInt32);

    //Throws a RuntimeBinderException
    Console.Write(shouldBeNullableInt32.HasValue);
}

Instead of being a Nullable<Int32> the return value get's treated as a dynamic type. And even then, the underlying Nullable<T> is not preserved. Since System.Int32 has no property named HasValue, a RuntimeBinderException is thrown.

I would be VERY curious to hear from someone who can actually explain what is happening (not just guess).

Two Questions

1. Why does shouldBeNullableInt32 get implicitly typed as a dynamic when the return type of GetNullableInt32 clearly returns a Nullable<Int32>?
2. Why is the underlying Nullable<Int32> not preserved? Why a dynamic{int} instead? (Answered here: C# 4: Dynamic and Nullable<>)

---

UPDATE

Both Rick Sladkey's answer and Eric Lippert's answer are equally valid. Please read them both :)

Answer 1

1. Why does shouldBeNullableInt32 get implicitly typed as a dynamic when the return type of GetNullableInt32 clearly returns a Nullable<Int32>?

This is because while it is apparent to us that GetNullableInt32 is the method that is going to be called, because of dynamic binding, the actual method that does get called is deferred until run-time because it is being called with a dynamic parameter. There might be another overload of GetNullableInt32 that matches better the run-time value of thisIsAnInt32. That alternate method, which cannot be known until run-time, might return some other type than Int32?!

As a result, the compiler, due to dynamic binding instead of static binding, cannot assume what the return type of the expression is at compile time and so the expression returns type dynamic. This can be seen by hovering over var.

You appear to have already come to a satisfactory explanation for your second question here:

• C# 4: Dynamic and Nullable<>

Answer 2

Rick's answer is good, but just to summarize, you are running into the consequences of two basic design principles of the feature:

1. if you ask for dynamic binding then you get dynamic binding.
2. dynamic is just object wearing a funny hat.

The first issue you identify is a consequence of the first design principle. You asked for analysis of the call to be deferred until runtime. The compiler did so. That includes deferring everything about the call until runtime, including overload resolution and determining the return type. The fact that the compiler has enough information to make a guess about what you meant is irrelevant.

And if the compiler did make a guess about what you meant, then right now you'd be asking a different question, namely, "I made a tiny change to the set of methods available and suddenly the compiler changed its deduction of the type to dynamic, why?" It is very confusing to users when the compiler's behaviour is unpredictable.

(All that said, there are a small number of situations in which the compiler will tell you that dynamic code is wrong. There are situations where we know that a dynamic binding will always fail at runtime, and we can tell you about them at compile time rather than waiting for your test case to fail.)

The second issue you identify is a consequence of the second design principle. Because dynamic is just object wearing a funny hat, and because nullables box to either a null reference or a boxed non-nullable value type, there is no such thing as a "dynamic nullable".