Introduction

This behavior usually surprises people when a method wants to return Task<TBase> but the code you already have returns Task<TDerived>. The compiler rejects the direct return because Task<T> is invariant, but it accepts the async and await version because awaiting extracts the inner value, applies the normal value conversion from TDerived to TBase, and then wraps it back into a new Task<TBase>.

The Core Type-System Reason

Task<T> is not covariant. That means a Task<Dog> cannot be used wherever a Task<Animal> is expected, even though Dog is an Animal.

This fails:

Task<Dog> dogTask = GetDogAsync();
Task<Animal> animalTask = dogTask; // compile-time error

The compiler is protecting type safety because Task<T> is a concrete generic type, not a covariant interface such as IEnumerable<out T>.

Why await Changes The Situation

When you write:

1async Task<Animal> GetAnimalAsync()
2{
3    return await GetDogAsync();
4}

this is conceptually closer to:

1async Task<Animal> GetAnimalAsync()
2{
3    Dog dog = await GetDogAsync();
4    Animal animal = dog;
5    return animal;
6}

The important difference is that the conversion happens on the result value after the task completes, not on the task object itself.

Direct Return Versus Awaited Return

Compare these two methods:

1Task<Animal> Wrong()
2{
3    return GetDogAsync();
4}
5
6async Task<Animal> Right()
7{
8    return await GetDogAsync();
9}

Wrong tries to return a Task<Dog> where Task<Animal> is required. That is a generic-type mismatch.

Right awaits the Task<Dog>, gets a Dog, upcasts it to Animal, and then the compiler-generated async state machine produces a Task<Animal> for the method.

A More General Example

The same pattern appears when the inner generic type is nested.

1using System.Collections.Generic;
2using System.Threading.Tasks;
3
4class Animal {}
5class Dog : Animal {}
6
7static Task<List<Dog>> GetDogsAsync() => Task.FromResult(new List<Dog> { new Dog() });
8
9static async Task<IEnumerable<Animal>> GetAnimalsAsync()
10{
11    return await GetDogsAsync();
12}

This works because the awaited expression produces a List<Dog> value, and that value can be converted to IEnumerable<Animal> through normal reference conversions and interface covariance. The task container itself never has to be converted directly.

Why The Compiler Cannot "Just Know"

It might seem like the compiler could look through the task automatically, but that would be a special rule that changes the meaning of generic type conversion. C# keeps those rules explicit:

• generic task types are checked normally
• 'await unwraps the task result'
• ordinary value conversions apply after unwrapping

This keeps the type system predictable.

Performance Question

People often worry that adding async and await only for the conversion creates overhead. It does add a small amount of async state-machine machinery. Sometimes that is acceptable because the type conversion is necessary and the code remains clear.

If you want to avoid an async method wrapper, you can project the task result explicitly.

1Task<Animal> GetAnimalAsync()
2{
3    return GetDogAsync().ContinueWith(t => (Animal)t.Result);
4}

That works, but it is usually less readable and has its own behavior tradeoffs.

Common Pitfalls

The most common mistake is assuming covariance of the inner type automatically makes Task<TDerived> assignable to Task<TBase>. It does not.

Another mistake is thinking await changes the original task’s type. It does not. It unwraps the value and lets normal conversions happen on that value.

A third issue is using ContinueWith as a reflex to avoid async and ending up with harder-to-read continuation code.

Summary

• 'Task<T> is invariant, so Task<TDerived> is not assignable to Task<TBase>.'
• 'await unwraps the inner value, which can then be converted normally.'
• The compiler accepts the async version because it returns a new Task<TBase> built from the converted result.
• The difference is between converting a task object and converting the awaited value.
• When clarity matters, async and await are usually the cleanest expression of this conversion.