>>I'd agree that 'out' would be cumbersome with more than one (or possibly two) parameters. But how would you write a better version of TryParse() ?
>
>Probably we will disagree in the definition of better :)
>
>I try to avoid out and ref parameters as much as I can, not sure if it is a good thing or not, but it is who I am, in the case of TryParse I would return null if it was not successful and the code would be almost the same, take for, for example, the sample code from the help:
>
>

>string[] dateStrings = {"05/01/2009 14:57:32.8", "2009-05-01 14:57:32.8", 
>                        "2009-05-01T14:57:32.8375298-04:00", 
>                        "5/01/2008 14:57:32.80 -07:00", 
>                        "1 May 2008 2:57:32.8 PM", "16-05-2009 1:00:32 PM", 
>                        "Fri, 15 May 2009 20:10:57 GMT" };
>DateTime dateValue;
>
>Console.WriteLine("Attempting to parse strings using {0} culture.", 
>                  CultureInfo.CurrentCulture.Name);
>foreach (string dateString in dateStrings)
>{
>   if (DateTime.TryParse(dateString, out dateValue)) 
>      Console.WriteLine("  Converted '{0}' to {1} ({2}).", dateString, 
>                        dateValue, dateValue.Kind);
>   else
>      Console.WriteLine("  Unable to parse '{0}'.", dateString);
>}
>

>
>Very simple to change, assuming that TryParse returns null for a failed attempt:
>
>

>string[] dateStrings = {"05/01/2009 14:57:32.8", "2009-05-01 14:57:32.8", 
>                        "2009-05-01T14:57:32.8375298-04:00", 
>                        "5/01/2008 14:57:32.80 -07:00", 
>                        "1 May 2008 2:57:32.8 PM", "16-05-2009 1:00:32 PM", 
>                        "Fri, 15 May 2009 20:10:57 GMT" };
>DateTime? dateValue;
>
>Console.WriteLine("Attempting to parse strings using {0} culture.", 
>                  CultureInfo.CurrentCulture.Name);
>
>foreach (string dateString in dateStrings)
>{  dateValue = (DateTime.TryParse(dateString) 
>   if (dateValue != null)
>      Console.WriteLine("  Converted '{0}' to {1} ({2}).", dateString, 
>                        dateValue, dateValue.Kind);
>   else
>      Console.WriteLine("  Unable to parse '{0}'.", dateString);
>}
>

>
>So just a change in the declaration of dateValue and an extra line to do first the assignment and then the test instead of having all in one go, a little price to avoid the awful out :) (of course you might argue that null is even worse, but I never understood why it is treated with such distrust)

Only disadvantage I can see is that initialization of a Nullable T is more expensive. Since TryParse() and nullable types were introduced at the same time I assume MS thought the same ?

BTW you could use dateValue.HasValue instead of 'dateValue !=null'...