8

I wanted to write an extension-method that would work on dictionaries whose values were some sort of sequence. Unfortunately, the compiler can't seem to infer the generic arguments from my usage of the method; I need to specify them explicitly.

public static void SomeMethod<TKey, TUnderlyingValue, TValue> (this IDictionary<TKey, TValue> dict) where TValue : IEnumerable<TUnderlyingValue> { } static void Usage() { var dict = new Dictionary<int, string[]>(); var dict2 = new Dictionary<int, IEnumerable<string>>(); //These don't compile dict.SomeMethod(); SomeMethod(dict); // doesn't have anything to do with extension-methods dict2.SomeMethod(); // hoped this would be easier to infer but no joy //These work fine dict.SomeMethod<int, string, string[]>(); dict2.SomeMethod<int, string, IEnumerable<string>>(); }

I realize that type inference isn't an exact science, but I was wondering if there's some fundamental 'rule' I'm missing here - I'm not familiar with the details of the spec.

  1. Is this a shortcoming of the inference process or is my expectation that the compiler should "figure it out" unreasonable in this case (ambiguity perhaps)?
  2. Can I change the method's signature in a way that would make it equally functional yet 'inferrable'?
Improve this question
3
  • Inferring TUnderlyingValue might be difficult. Especially since the type parameter of IEnumerable<> is covariant in .net 4. Commented Oct 19, 2010 at 13:36
  • 5
    Type inference is an exact science that has formal algorithms, it's not just a guess. If a compiler is not able to infer a type it is just because it doesn't have specific rules to handle some cases, and it is usually an implementation design, not a limit. Take a look here: classes.cs.uchicago.edu/archive/2005/winter/33600-1/slides/… Commented Oct 19, 2010 at 13:37
  • @Jack: Thanks for the link; that's interesting. See my comment on Eric Lippert's answer for what I meant by that. Poor choice of words on my part I suppose. Commented Oct 20, 2010 at 15:49

3 Answers 3

Reset to default
16

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://learn.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.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Brilliant, thanks - "constraints are not part of the signature" is what I was missing, and I have to wrap my head around that. On another note, what I meant by "not an exact science" is that it would be possible for two different but valid inference algorithms (in general, not specific to the spec) to infer the type arguments differently, yet both be justified in their choice. Do you agree?
@Ani: Absolutely, there are many different possible type inferencers. We made a deliberate choice to not use Hindley-Milner-style type inference in C#, for example.
What's the name of the type inference that you guys used? Just wondering if it's invented by someone else like the Hindley-Milner-style type inference (I assume).
@Joan: We don't have a name for it. It was a joint effort of the whole C# design committee. In particular, Anders, Mads, and I worked heavily on it. Erik Meijer and some of the Microsoft Research team members also contributed many useful ideas, particularly in the area of how to resolve cyclic situations. I do not recall who all is on the patent declaration.
Eric, I don't know if you'll notice this new comment, ever, but I wanted to ask you something about the debate on that link you gave. One thing I feel people fail to ask - why do "neither the CLR nor C# considers constraints to be part of the signature"? Why not add that into the spec? Do you have a link to give the position on this? Thanks.
4

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.

Improve this answer

3 Comments

+1 @Philip Rieck: Thanks. I'm aware of this workaround, but it doesn't solve the general case, which is what I'm interested in.
@Ani see edits - I'm not sure that the type inference defined and implemented in c# 4.0 supports that level of inference at all.
This will not work with Dictionary<string, List<int>> because IDictionary is an invariant type. Suppose the method body contained this: dict.Add(new ObservableCollection<int>());. If there was an IReadOnlyDictionary interface of some sort, it could be made covariant on the value parameter and allow both dictionaries to work.
1

Why not leave out the type of the IEnumerable?

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

2 Comments

Because then you won't (short of reflection) have access to the type of the underlying values - all you will know is that each Value is a sequence of something, but not what that something is.
You could cast TValue to IEnumerable<TValue> because you know it's of the type.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.