Lambda Expression for Class Property

Question

Can someone explain why the first of the two following examples is valid and the other is not? More specifically, how is a relationship created between T and TProperty in the first example?

//Example 1  
class SomeClass<T> where T : class
{
    void SomeMethod<TProperty>( Expression<Func<T,TProperty>> expression ){ ... }
}

//Example 2  
class SomeClass
{
    void SomeMethod<T,TProperty>( Expression<Func<T,TProperty>> expression ) 
         where T : class{ ... }
}

Given the two examples I would expect that the following implementations would work, but the second one does not.

//Implementation w/ Example 1  
var sc = new SomeClass<MyDateClass>();
sc.SomeMethod( dt => dt.Year );

//Implementation w/ Example 2
var sc = new SomeClass();
sc.SomeMethod<MyDateClass>( dt => dt.Year );

What I'm having difficulty wrapping my mind around is how the first example/implementation can ignore the TProperty generic type when executing SomeMethod, yet the second example/implementation can't and how an implicit relationship seems to be established between T and TProperty in example/implementation 1.

Solution Change signature of method in example 2 as follows:

void SomeMethod<T>( Expression<Func<T,Object>> expression ){ ... }

While this will allow arbitrary objects to be used in the expression as a result it does allow for property articulation as described in implementation 2.

Answer 1

You're allowing the compiler to infer the type parameters. This works fine for case 1:

class SomeClass<T> where T : class {
    void SomeMethod<TProperty>( Expression<Func<T,TProperty>> expression ){ ... }
}

because you first declare an instance:

var sc = new SomeClass<MyDateClass>();

which tells the compiler that T is MyDateClass. Then, when you call the method:

sc.SomeMethod( dt => dt.Year );

the compiler knows that T is MyDateClass, so T.Year must be an int. That's enough info to resolve SomeMethod as SomeMethod<MyDateClass, int>.

Your second example, however, is explicitly stating the type parameter(s) - telling the compiler to not infer it:

sc.SomeMethod<MyDateClass>( dt => dt.Year );

Unfortunately, it is trying to call SomeMethod with only a single type parameter (the <MyDateClass> bit). Since that doesn't exist, it'll complain and say you need 2 type parameters.

If, instead, you were to call it like you did the first example:

sc.SomeMethod( dt => dt.Year );

The compiler will complain, telling you that it cannot infer the type parameters - there's simply not enough info to determine what dt is. So, you could explicitly state both type parameters:

sc.SomeMethod<MyDateClass, int>( dt => dt.Year );

Or, tell the compiler what dt is (which is what you did in the first example by newing SomeClass<MyDateClass>):

sc.SomeMethod((MyDateClass dt) => dt.Year );

Edits and Updates:

So effectively the compiler is performing magic in the first example? Making an assumption that TProperty should be an int because .Year is an int? That would answer my question, can't say it's satisfying though.

Not really magic, but a series of small steps. To illustate:

1. sc is of type SomeClass<MyDateClass>, making T = MyDateClass
2. SomeMethod is called with a parameter of dt => dt.Year.
3. dt must be a T (that's how SomeMethod is defined), which must be a MyDateClass for the instance sc.
4. dt.Year must be an int, as MyDateClass.Year is declared an int.
5. Since dt => dt.Year will always return an int, the return of expression must be int. Therefore TProperty = int.
6. That makes the parameter expression to SomeMethod, Expression<Func<MyDateClass,int>>. Recall that T = MyDateClass (step 1), and TProperty = int (step 5).
7. Now we've figured out all of the type parameters, making SomeMethod<T, TProperty> = SomeMethod<MyDateClass, int>.

[B]ut what's the difference between specifying T at the class level and specifying at the method level? SomeClass<SomeType> vs. SomeMethod<SomeType>... in both cases T is known is it not?

Yes, T is known in both cases. The problem is that SomeMethod<SomeType> calls a method with only a single type parameter. In example 2, there are 2 type parameters. You can either have the compiler infer all type parameters for the method, or none of them. You can't just pass 1 and have it infer the other (TProperty). So, if you're going to explicitly state T, then you must also explicitly state TProperty.

Answer 2

First of all, your first example is incorrect, and won't compile as given. Aside from the missing public on the method, you define T twice - once on class, and once on method. This isn't an error in and of itself (though you'll get a warning), but when compiling the method call, you'll get the same error as you describe getting for example #2. So, I assume the actual code is like this:

//Example 1  
class SomeClass<T> where T : class
{
  public void SomeMethod<TProperty>(Expression<Func<T,TProperty>> expression) {}
}

Furthermore, both your examples "ignore" (that is, infer) the actual type of TProperty in your call to SomeMethod. Your second example explicitly specifies the type of T, yes, but not TProperty.

There's no implicit relationship established in the first example, either. When you instantiate SomeClass<> with T=MyDateClass, the signature of SomeMethod for that instantiation effectively becomes:

void SomeMethod<TProperty>(Expression<Func<MyDateClass, TProperty>> expression)

So the argument type of the lambda is known at this point, so you don't have to specify it. The return type of expression lambda is inferred as the type of expression on the right of =>, and that will be the inferred type of TProperty.

In the second example, since T was not explicitly specified when instantiating the class, and since there's no way to infer it from method arguments, it has to be specified explicitly. Once you specify it, TProperty is inferred in exact same way as for example #1.

Answer 3

Rather than typing out the specifics, please take a look at this post by Eric Lippert. I think it will answer what you're attempting to ask.

I realize it's long and contrived, but I think it's the best bang for the buck for answering you.