“Use of unassigned local variable” in if statement with TryParse with the use of dynamic

Question

I've just typed in the following code to a VS2015 .Net v4.5.2 console application:

dynamic fromString = "blah", toString = "blah2";
DateTime fromDate, toDate;
if (DateTime.TryParse(fromString.ToString(), out fromDate) && DateTime.TryParse(toString.ToString(), out toDate)) {
    Console.WriteLine(fromDate);
    Console.WriteLine(toDate); 
}

Somewhat unexpectedly I'm getting the error "Use of unassigned local variable toDate". I didn't expected it because the if statement is only entered if 'toDate' is assigned a value from the second TryParse.

Needless to say, it can be worked around by assigning 'toDate' a value:

DateTime fromDate, toDate = DateTime.MinValue;

or changing the && to & so that both TryParses are executed regardless of the first failing.

However, I wonder why the error occurs? If the variables fromString and toString were strings, the error does not occur and the compiler does not give the error that toDate is unassigned. Therefore I wonder why the compiler treats string and dynamic.ToString() differently?

Answer 1

This was a breaking change in Roslyn, documented here:

The definite assignment rules implemented by previous compilers for dynamic expressions allowed some cases of code that could result in variables being read that are not definitely assigned. See https://github.com/dotnet/roslyn/issues/4509 for one report of this.

[snip illustrative example]

Because of this possibility the compiler must not allow this program to be compiled if val has no initial value. Previous versions of the compiler (prior to VS2015) allowed this program to compile even if val has no initial value. Roslyn now diagnoses this attempt to read a possibly uninitialized variable.

Answer 2

This is because you use the short circuit operator &&, which means that if the first TryParse returns false, the second TryParse is never executed thus leaving the ToDate variable unassigned.

Try it, replace && by & and your error will disappear because both TryParse calls will now be always executed.

The compiler is just not clever enough (it doesn't analyse your logic) to know that the code inside won't be executed in some cases.

EDIT: @Simon, I've re-read your question and found that you already knew this... Maybe it's because .ToString always exist on an object but not always on a dynamic (for example when it's a com object), and in that case the compiler does less checks?