C# in Depth

246 CHAPTER 9 Lambda expressions and expression treesEven within this section I’m not going to go into absolutely every nook andcranny—that’s what the language specification is for. Instead, I’ll give an overview ofthe new behavior, providing examples of common cases. The primary reason forchanging the specification is to allow lambda expressions to work in a concise fashion,which is why I’ve included the topic in this particular chapter. Let’s look a little deeperat what problems we’d have run into if the C# team had stuck with the old rules.9.4.1 Reasons for change: streamlining generic method callsType inference occurs in a few situations. We’ve already seen it apply to implicitlytyped arrays, and it’s also required when you try to implicitly convert a method groupto a delegate type as the parameter to a method—with overloading of the methodbeing called, and overloading of methods within the method group, and the possibilityof generic methods getting involved, the set of potential conversions can becomequite overwhelming.By far the most common situation for type inference is when you’re calling ageneric method without specifying the type arguments for that method. This happensall the time in LINQ—the way that query expressions work depends on this heavily. It’sall handled so smoothly that it’s easy to ignore how much the compiler has to workout on your behalf, all for the sake of making your code clearer and more concise.The rules were reasonably straightforward in C# 2, although method groups andanonymous methods weren’t always handled as well as we might have liked. The typeinference process didn’t deduce any information from them, leading to situationswhere the desired behavior was obvious to developers but not to the compiler. Life ismore complicated in C# 3 due to lambda expressions—if you call a generic methodusing a lambda expression with an implicitly typed parameter list, the compiler needsto work out what types you’re talking about, even before it can check the lambdaexpression’s body.This is much easier to see in code than in words. Listing 9.11 gives an example of thekind of issue we want to solve: calling a generic method using a lambda expression.Listing 9.11Example of code requiring the new type inference rulesstatic void PrintConvertedValue(TInput input, Converter converter){Console.WriteLine(converter(input));}...PrintConvertedValue("I'm a string", x => x.Length);The method PrintConvertedValue in listing 9.11 simply takes an input value and adelegate that can convert that value into a different type. It’s completely generic—itmakes no assumptions about the type parameters TInput and TOutput. Now, look atthe types of the arguments we’re calling it with in the bottom line of the listing. Thefirst argument is clearly a string, but what about the second? It’s a lambda expression,so we need to convert it into a Converter—and that means weneed to know the types of TInput and TOutput.Licensed to Rhona Hadida