Tại sao giao diện chung không đồng/contravariant theo mặc định?

Question

Ví dụ giao diện IEnumerable<T>:

public interface IEnumerable<out T> : IEnumerable 
{ 
    IEnumerator<T> GetEnumerator(); 
} 

Trong giao diện này kiểu generic chỉ được sử dụng như một kiểu trả về của phương thức giao diện và không được sử dụng như một loại đối số phương pháp như vậy, nó có thể được hiệp biến. Đưa ra điều này, không thể trình biên dịch suy luận về mặt phương sai từ giao diện? Nếu có thể, tại sao C# yêu cầu chúng tôi đặt các từ khóa co/contravariance một cách rõ ràng.

Cập nhật: Như Jon Skeet nêu câu hỏi này có thể được spited thành các câu hỏi sau:

1. Can biên dịch suy luận chung loại của đồng/contravariance bởi cách nó được sử dụng bên trong loại generic hiện tại và tất cả đó là loại cơ sở?

   Ví dụ: Có bao nhiêu tham số giao diện chung từ .NET Framework 4.0 có thể được đánh dấu đồng/contravariant tự động mà không có bất kỳ sự mơ hồ nào? Khoảng 70%, 80%, 90% hoặc 100%?

2. Nếu có thể, nên áp dụng đồng/contravariance cho loại chung theo mặc định? Ít nhất là với những loại mà nó có khả năng phân tích và phỏng đoán co/contravariance từ việc sử dụng loại.

Answer 1

Vâng, có hai câu hỏi ở đây. Thứ nhất, có thể trình biên dịch luôn làm như vậy? Thứ hai, nên nó (nếu có thể)?

Đối với câu hỏi đầu tiên, tôi sẽ hoãn đến Eric Lippert, người đã nhận xét này khi tôi mang chính xác vấn đề này lên trong ấn bản lần thứ 2 của C# trong Depth:

Nó không rõ ràng với tôi rằng chúng ta hợp lý thậm chí có thể nếu chúng ta muốn. Chúng ta có thể dễ dàng tìm ra với các tình huống đòi hỏi phải phân tích toàn cầu tất cả các giao diện trong một chương trình để tìm ra các phương sai và chúng ta có thể dễ dàng tìm ra các tình huống trong đó <in T, out U> hoặc <out T, in U> và không có cách nào để quyết định giữa chúng. Với cả hai trường hợp xấu và hiệu suất là , các trường hợp không rõ ràng là một tính năng không chắc chắn.

(Tôi hy vọng Eric không ngại tôi trích dẫn nguyên văn này; anh ấy trước đây đã được rất tốt về việc chia sẻ những hiểu biết như vậy, nên tôi sẽ bằng hình thức quá khứ :)

Mặt khác, tôi nghi ngờ vẫn còn những trường hợp mà nó có thể được suy ra không có sự mơ hồ, do đó, điểm thứ hai vẫn có liên quan ...

Tôi không nghĩ rằng nó phải tự động ngay cả khi trình biên dịch có thể biết rõ ràng rằng nó hợp lệ chỉ một chiều. Trong khi mở rộng một giao diện luôn luôn là một thay đổi phá vỡ ở một mức độ nào đó, thường thì không phải nếu bạn là người duy nhất thực hiện nó. Tuy nhiên, nếu mọi người đang dựa vào giao diện của bạn là biến thể, bạn có thể không phải là có thể để thêm phương thức vào giao diện đó mà không vi phạm khách hàng ... ngay cả khi họ chỉ là người gọi chứ không phải người thực hiện. Các phương thức bạn thêm vào có thể thay đổi giao diện trước đó biến đổi để trở thành bất biến, tại thời điểm đó bạn phá vỡ bất kỳ người gọi nào đang cố gắng sử dụng nó một cách tương đối.Về cơ bản, tôi nghĩ rằng nó là tốt để yêu cầu này phải rõ ràng - đó là một quyết định thiết kế bạn nên làm một cách có ý thức, chứ không chỉ là vô tình kết thúc với hiệp phương sai/contravariance mà không cần suy nghĩ về nó.

Answer 2

This article giải thích rằng có những tình huống mà các trình biên dịch không thể suy ra và vì vậy nó cung cấp cho bạn với cú pháp rõ ràng:

interface IReadWriteBase<T> 
{ 
    IReadWrite<T> ReadWrite(); 
} 

interface IReadWrite<T> : IReadWriteBase<T> 
{ 

} 

Bạn suy luận gì ở đây in hoặc out, cả hai công việc?