Może/powinien Zadanie <TResult> być zapakowane w C# 5.0, co jest kowariantne w TResult?

Question

Naprawdę lubię pracować z programowaniem asynchronicznym C# 5.0. Jest jednak kilka miejsc, w których aktualizacja starego kodu, który jest zgodny z modelem TAP, sprawia mi problemy.

Oto jeden z nich - nie jestem pewien dokładnie dlaczego Task<TResult> nie kowariantna w TResult, ale to powoduje problemy dla mnie podczas próby aktualizacji kowariantna interfejs przenieść z synchronicznym do asychronous wzoru:

stary kod:

public interface IInitializable<out T> // ** out generic modifier ** 
{ 
    /// <summary> 
    /// Boolean to indicate if class is ready 
    /// </summary> 
    bool IsInitialized { get; } 

    /// <summary> 
    /// Calls for instance to be initialized using current parameters 
    /// Driver initialization can be done in the default constructor if desired 
    /// </summary> 
    T Initialize(); 
} 

Nowy kod (nie będzie skompilować):

public interface IAsyncInitializable<out T> // ** out generic modifier...broken ** 
{ 
    /// <summary> 
    /// Boolean to indicate if class is ready 
    /// </summary> 
    bool IsInitialized { get; } 

    /// <summary> 
    /// Calls for instance to be initialized using current parameters 
    /// Driver initialization can be done in the default constructor if desired 
    /// </summary> 
    Task<T> InitializeAsync(); // ** breaks because Task<TResult> is invariant in TResult ** 
} 

Czy istnieje rozsądny sposób obejść bez MO zbyt drastycznie ograniczasz moje interfejsy API? (Bonus: dlaczego Zadanie nie jest kowariantne?). Nie ma interfejsu IAwaitable, ale przypuszczam, że mógłbym go stworzyć i stworzyć metodę rozszerzenia, która przekształca się w owinięty, kowariantny, trwały obiekt zadania. Czy robię to źle?

Answer 1

Task<T> nie może być kowariantny w T, ponieważ jest klasą. Tylko interfejsy i delegaci mogą mieć ogólną wariancję.

Co do tego, czy warto robić opakowanie ... Myślę, że to zależy od tego, ile wykorzystujesz kowariancji w swoim projekcie. Podejrzewam, że z czasem odkryjesz, że całe pakowanie i rozpakowywanie jest mylące - jeśli nie jest to złe, aby po prostu odnieść skutek usunięcia kowariancji, zrobiłbym to.

Answer 2

Uważam, że nie uwzględnienie obsługi asynchronicznego słowa kluczowego async w interfejsie ITask było poważnym niedopatrzymaniem ze strony Microsoftu. Na szczęście nie jest zbyt trudno obejść to ograniczenie.

Zaimplementowałem interfejs, którego nie można zmienić na ITask<out TResult>. Jego użycie jest całkiem proste.

Więcej informacji można znaleźć na stronie:

https://github.com/jam40jeff/ITask