Generics: Why can't the compiler infer the type arguments in this case?

Solution 1:

UPDATE: This answer was written over ten years ago; since then the type inference specification and implementation have been updated several times including changes to how constraints are used during inference. This answer should be considered of historical interest only; consult a recent copy of the C# specification to see how type inference works in current implementations.

I realize that type inference isn't an exact science

I'm not sure I agree. The spec is quite detailed.

I was wondering if there's some fundamental 'rule' I'm missing here

The fundamental rule that you're missing is probably that constraints are not part of the signature. Type inference works off of the signature.

There are in my opinion good reasons for that design decision. However, many people believe that I am morally wrong for believing that there are good reasons for that design decision. If you're interested in reading what feels like several million words on the topic of whether I'm right or wrong, see my article on the subject and the hundred or so comments telling me I'm wrong:

https://docs.microsoft.com/en-us/archive/blogs/ericlippert/constraints-are-not-part-of-the-signature

Is this a shortcoming of the inference process?

Arguably, yes. In my opinion, it is a reasonable choice given competing design requirements. (Those being "do what the user meant" and "give errors when things look ambiguous".)

is my expectation that the compiler should "figure it out" unreasonable in this case?

No. You seem like a reasonable person, and your expectation appears to be based on good reasoning. However, it is entirely possible to have a reasonable expectation that nevertheless is unmet. This would be one of those cases.

Can I change the method's signature in a way that would make it equally functional yet 'inferrable'?

That's going to be difficult, since the generic Dictionary type is not covariant or contravariant in its conversions. The concept you want to capture is not easily expressed in the type system in a manner that affords inference.

If you prefer using languages with more advanced type inference, consider using F#. If you prefer languages that skew towards "do what the user meant" rather than "report errors on ambiguity", consider using VB.

Solution 2:

C# type inference doesn't work off of constraints or return values. So you'll have slightly better luck with

public static void SomeMethod<TKey, TUnderlyingValue>
    (this IDictionary<TKey, IEnumerable<TUnderlyingValue>> dict)
  { }

This will work if you declare the param as new Dictionary< string, IEnumerable<int>>(), but not if you declare it new Dictionary<string, List<int>>().

I do have to say, that the way I read section 7.5.2 of the c# spec, it seems that since List<int> implements IEnumerable<int>, the type inference of TUnderlyingValue should work. However, that section isn't exactly straightforward to understand. I assume it does not work through the multiple "layers", since SomeMethod<T>(IEnumberable<T> val){} would work just fine calling it with SomeMethod(new List<string>()). I don't specifically see anything in the spec that deals with resolving a type where U = Ca<Va, Cb<Vb>>, so perhaps inference at that level is not defined.

Solution 3:

Why not leave out the type of the IEnumerable?

public static void SomeMethod<TKey, TValue>
(this IDictionary<TKey, TValue> dict)
where TValue : IEnumerable { }