This question is asked almost every day in some form.
The conditional operator type analysis proceeds from inside to outside, not outside to inside. The conditional operator does not know to what type its results are being assigned and then coerces the consequence and alternative to those types. It does the opposite; it works out the types of the consequence and alternative, takes the more general of those two types, and then verifies that the general type may be assigned.
The consequence and alternative contain no information about what the type of the lambda should be, and therefore the type of the conditional cannot be inferred. Therefore it cannot be verified that the assignment is correct.
It is edifying to consider why the language was designed that way. Suppose you have overloads:
void M(Func<string, int> f) {}
void M(Func<double, double> f) {}
and a call
M( b ? n=>n.Foo() : n => n.Bar() );
Describe how overload resolution determines which overload of M is chosen in a world where types are inferred from outside to inside.
Now consider this one:
M( b1 ? (b2 ? n=>n.Foo() : n => n.Bar() ) : (b3 ? n=>n.Blah() : n=>n.Abc()) );
Getting harder isn't it? Now imagine that Foo, Bar, Blah and Abc were themselves methods that took funcs, and also had arguments with conditional operators containing lambdas.
We do not wish to make the type inference process so complex without a corresponding huge benefit, and there is no such huge benefit for the conditional operator.
What you should do in your case is cast one or both of the consequence and alternative to the specific type.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…