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

by

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.

More Related Contents:

  1. Why can’t the C# constructor infer type?
  2. Why must I provide explicitly generic parameter types While the compiler should infer the type?
  3. Partial generic type inference possible in C#?
  4. C# 3.0 generic type inference – passing a delegate as a function parameter
  5. KeyValuePair with generic values [closed]
  6. How do I clone a generic list in C#?
  7. Remove duplicates from a List in C#
  8. How to dynamically create generic C# object using reflection? [duplicate]
  9. Why doesn’t C# infer my generic types?
  10. Why isn’t there generic variance for classes in C# 4.0?
  11. Generics and casting – cannot cast inherited class to base class
  12. What is the best way to clone/deep copy a .NET generic Dictionary?
  13. Generic TryParse
  14. Generic constraints, where T : struct and where T : class
  15. Nullable type issue with ?: Conditional Operator
  16. How do I implement IEnumerable
  17. What does “where T : class, new()” mean?
  18. Generic All Controls Method
  19. Nullable reference types with generic return type
  20. Generic type conversion FROM string
  21. C# Generics won’t allow Delegate Type Constraints
  22. Generic C# Code and the Plus Operator [duplicate]
  23. Curiously Recurring Template Pattern and generics constraints (C#)
  24. Why generic IList does not inherit non-generic IList
  25. Is there a generic constraint I could use for the + operator?
  26. How to convert string to any type
  27. List readonly with a private set
  28. Creating a generic method in C#
  29. How does Java’s use-site variance compare to C#’s declaration site variance?
  30. Convert DataTable to Generic List in C#

Leave a Comment