Generics: Tại sao trình biên dịch không thể suy ra các đối số kiểu trong trường hợp này?

Question

Tôi muốn viết một phương pháp mở rộng sẽ hoạt động trên các từ điển có giá trị là một số loại chuỗi. Thật không may, trình biên dịch dường như không thể suy ra các đối số chung từ việc sử dụng phương thức của tôi; Tôi cần phải xác định rõ ràng.

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>>(); 
} 

Tôi nhận ra rằng suy luận kiểu không phải là khoa học chính xác, nhưng tôi tự hỏi liệu có một số 'quy tắc' cơ bản tôi thiếu ở đây - tôi không quen với các chi tiết của thông số.

1. Đây có phải là một thiếu sót của quá trình suy luận hay là kỳ vọng rằng trình biên dịch sẽ "tìm ra" không hợp lý trong trường hợp này (không rõ ràng)?
2. Tôi có thể thay đổi chữ ký của phương thức theo cách có thể làm cho nó hoạt động bình thường như 'không thể sửa'?

Answer 1

Tôi nhận ra rằng suy luận kiểu không phải là một khoa học chính xác

Tôi không chắc chắn Tôi đồng ý. Thông số kỹ thuật khá chi tiết.

Tôi đã tự hỏi nếu có một số cơ bản 'quy tắc' Tôi đang mất tích ở đây

Nguyên tắc cơ bản mà bạn đang thiếu là lẽ rằng những hạn chế không phải là một phần của chữ ký. Loại suy luận hoạt động tắt chữ ký.

Có nhiều lý do chính đáng cho quyết định thiết kế của tôi. Tuy nhiên, nhiều người tin rằng tôi sai về mặt đạo đức vì tin rằng có những lý do chính đáng cho quyết định thiết kế đó. Nếu bạn quan tâm đến việc đọc những gì cảm thấy như vài triệu từ về chủ đề liệu tôi có đúng hay sai, hãy xem bài viết của tôi về chủ đề và hàng trăm ý kiến ​​nói với tôi rằng tôi sai:

http://blogs.msdn.com/b/ericlippert/archive/2009/12/10/constraints-are-not-part-of-the-signature.aspx

Đây có phải là thiếu sót của quy trình suy luận không?

Có thể cho là có. Theo tôi, đó là một sự lựa chọn hợp lý cho các yêu cầu thiết kế cạnh tranh. (Đó là "làm những gì người dùng có ý nghĩa" và "đưa ra lỗi khi mọi thứ trông mơ hồ".)

là kỳ vọng rằng trình biên dịch nên "tìm ra" không hợp lý trong trường hợp này?

Không. Bạn có vẻ như một người hợp lý và kỳ vọng của bạn dường như dựa trên lý do chính đáng. Tuy nhiên, hoàn toàn có thể có một kỳ vọng hợp lý mà vẫn chưa được đáp ứng. Đây sẽ là một trong những trường hợp đó.

Tôi có thể thay đổi chữ ký của phương thức theo cách làm cho nó hoạt động bình thường như 'không thể sửa'?

Điều đó sẽ rất khó, vì loại từ điển chung chung không phải là biến thể hoặc contravariant trong chuyển đổi của nó. Khái niệm bạn muốn chụp không dễ dàng được thể hiện trong hệ thống kiểu theo cách suy luận.

Nếu bạn thích sử dụng ngôn ngữ có suy luận kiểu nâng cao hơn, hãy cân nhắc sử dụng F #. Nếu bạn thích ngôn ngữ nghiêng về "làm những gì người dùng có nghĩa là" thay vì "báo cáo lỗi về sự mơ hồ", hãy xem xét sử dụng VB.

Answer 2

Tại sao không loại bỏ loại IEnumerable?

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

Answer 3

C# kiểu suy luận không hoạt động do các ràng buộc hoặc giá trị trả lại. Vì vậy, bạn sẽ có may mắn hơi tốt hơn với

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

Điều này sẽ có tác dụng nếu bạn khai báo các param như new Dictionary< string, IEnumerable<int>>(), nhưng không nếu bạn khai báo nó new Dictionary<string, List<int>>().

Tôi có thể nói, rằng con đường tôi đọc phần 7.5.2 của c# spec, có vẻ như rằng kể từ khi thực hiện List<int>IEnumerable<int>, những suy luận kiểu của TUnderlyingValue nên làm việc. Tuy nhiên, phần đó không thực sự dễ hiểu. Tôi giả sử nó không hoạt động thông qua nhiều "lớp", vì SomeMethod<T>(IEnumberable<T> val){} sẽ hoạt động tốt khi gọi nó với SomeMethod(new List<string>()). Tôi không thấy cụ thể bất cứ điều gì trong spec đó đề cập đến việc giải quyết một loại ở đâu đó U = Ca<Va, Cb<Vb>>, vì vậy có lẽ suy luận ở cấp đó không được xác định.