Task and Task<T>

A Task is an object that stands for work which may not have finished yet.

That is an unfamiliar idea at first, because every method you have written so far returned a finished answer. A method returning decimal hands you a number. A method returning Task<decimal> hands you something else: a promise that a number will exist, along with a way to find out when.

A cloakroom ticket is a fair comparison. The ticket is not your coat. It is proof that a coat is being looked after, and the means of collecting it later. You can hold the ticket, pass it to a friend, or go and collect the coat — but the ticket itself is not the thing you wanted.

This trips people up, so it is worth stating plainly. When a method returns a Task to you, the work has normally already been started. The request has been sent. The file read is under way.

You do not start it, and there is nothing to switch on. Your choice is when to collect the result — and whether to do something else first.

It is possible to create a task that has not been started, using a constructor and calling Start on it. Do not. That form exists for historical reasons and has no place in modern code. Every task you meet in practice arrives already in flight.

public class OrderReportService
{
    private readonly IOrderStore _orders;
    private readonly IRateService _rates;

    public OrderReportService(IOrderStore orders, IRateService rates)
    {
        _orders = orders;
        _rates = rates;
    }

    public async Task<string> BuildSummaryAsync(int customerId)
    {
        // Both calls are in flight from this point. Neither has been awaited.
        Task<List<Order>> ordersTask = _orders.GetForCustomerAsync(customerId);
        Task<decimal> rateTask = _rates.GetRateAsync("GBP");

        // Collect the results. The two waits overlap.
        List<Order> orders = await ordersTask;
        decimal rate = await rateTask;

        decimal total = orders.Sum(order => order.Amount) * rate;

        return $"{orders.Count} orders, {total:N2} GBP";
    }
}

• Line by line, the first call starts fetching orders and immediately hands back a Task<List<Order>>. Execution moves on. The second call starts fetching the rate.
• By the time the third statement runs, both round trips are already happening. Neither call blocked.
• await ordersTask means "I need the value now". If the orders have already arrived, it continues immediately; if not, the thread is released until they do.
• The second await often costs nothing, because the rate has been arriving while the orders were being fetched.
• Compare this with awaiting each call on the line that makes it. That version takes as long as the two round trips added together. Here it takes as long as the slower of the two. The next lesson covers a clearer way to express this with Task.WhenAll.
• Note what the method returns: Task<string>, not string. Asynchrony is visible in the signature all the way up the call chain.

Sometimes a method must return a Task because an interface says so, but a particular implementation has nothing to wait for. A cache that already holds the value, or a test double that returns fixed data, or a validation step that decides nothing needs saving.

Two helpers cover this without pretending work is happening.

public interface IInvoiceStore
{
    Task<Invoice?> FindAsync(string reference);
    Task SaveAsync(Invoice invoice);
}

public class InMemoryInvoiceStore : IInvoiceStore
{
    private readonly Dictionary<string, Invoice> _invoices = new();

    public Task<Invoice?> FindAsync(string reference)
    {
        _invoices.TryGetValue(reference, out Invoice? invoice);

        // Already-completed task carrying a value. No thread, no waiting.
        return Task.FromResult(invoice);
    }

    public Task SaveAsync(Invoice invoice)
    {
        _invoices[invoice.Reference] = invoice;

        // Already-completed task with no value.
        return Task.CompletedTask;
    }
}

• Neither method is marked async, because neither awaits anything. Adding async here would add machinery for no reason and the compiler would warn about it.
• Task.FromResult wraps a value you already have in a task that is complete the moment it is created. Awaiting it does not release the thread, because there is nothing to wait for.
• Task.CompletedTask is the same idea with no value. It is a single shared instance, so it allocates nothing.
• This pattern is how you write fast test doubles for asynchronous interfaces, and it is worth recognising when reading library code.