C# in Depth

Changes to type inference and overload resolution251phase 2, TMiddle is fixed to int and we infer that there must be a conversion fromdouble to TOutput. The third time through phase 2, TOutput is fixed to double andtype inference succeeds. When type inference has finished, the compiler can look atthe code within the lambda expression properly.NOTEChecking the body of a lambda expression—The body of a lambda expressioncannot be checked until the input parameter types are known. The lambdaexpression x => x.Length is valid if x is an array or a string, but invalid inmany other cases. This isn’t a problem when the parameter types areexplicitly declared, but with an implicit parameter list the compiler needsto wait until it’s performed the relevant type inference before it can try towork out what the lambda expression means.These examples have shown only one change working at a time—in practice there canbe several pieces of information about different type variables, potentially discoveredin different iterations of the process. In an effort to save your sanity (and mine), I’mnot going to present any more complicated examples—hopefully you understand thegeneral mechanism, even if the exact details are hazy.Although it may seem as if this kind of situation will occur so rarely that it’s notworth having such complex rules to cover it, in fact it’s quite common in C# 3, particularlywith LINQ. Indeed, you could easily use type inference extensively without eventhinking about it—it’s likely to become second nature to you. If it fails and you wonderwhy, however, you can always revisit this section and the language specification.There’s one more change we need to cover, but you’ll be glad to hear it’s easierthan type inference: method overloading.9.4.4 Picking the right overloaded methodOverloading occurs when there are multiple methods available with the same namebut different signatures. Sometimes it’s obvious which method is appropriate, becauseit’s the only one with the right number of parameters, or it’s the only one where allthe arguments can be converted into the corresponding parameter types.The tricky bit comes when there are multiple methods that could be the right one.The rules are quite complicated (yes, again)—but the key part is the way that eachargument type is converted into the parameter type. For instance, consider thesemethod signatures, as if they were both declared in the same type:void Write(int x)void Write(double y)The meaning of a call to Write(1.5) is obvious, because there’s no implicit conversionfrom double to int, but a call to Write(1) is trickier. There is an implicitconversion from int to double, so both methods are possible. At that point, thecompiler considers the conversion from int to int, and from int to double. A conversionfrom any type to itself is defined to be better than any conversion to a differenttype, so the Write(int x) method is better than Write(double y) for thisparticular call.Licensed to Rhona Hadida