Looking at c#'s Task>

Damiaan — Mon, 26 May 2025 13:56:30 +0000

On the surface, Task<IEnumerable<T>> looks harmless — you're just asynchronously returning a list of things. But under the hood, there's a mismatch between what the caller sees and what the code actually does.

Let’s unpack it.

1. `IEnumerable<T>` is Lazy by Design

The IEnumerable interface represents a deferred execution model. It doesn’t hold data — it describes a computation that yields data when enumerated.

IEnumerable<int> GetNumbers() { yield return 1; yield return 2; }

Here, GetNumbers() doesn’t do anything until the caller starts iterating. It’s not a collection — it’s a generator.

2. `Task<IEnumerable<T>>` Suggests Lazy + Async — But It’s Not

Let’s say you write:

public async Task<IEnumerable<User>> GetUsersAsync() { return await _context.Users.ToListAsync(); }

You're returning a fully materialized list, but your method signature doesn’t say that. To the caller, this looks like:

"I'm going to give you a lazily-evaluated collection — once the async operation is done."

This is misleading because:

The data is already in memory.
IEnumerable<T> can be enumerated multiple times, each of which may repeat logic or side effects.
But here, re-enumerating just re-reads the in-memory list — not re-executes anything — and that behavior is hidden.

3. Async Methods use State Machines — But not for IEnumerable

When you await in a method, the compiler rewrites it into a state machine — tracking the position across awaits. However:

This async state machine wraps only the outer method body.
It doesn’t know how or when the returned IEnumerable<T> will be used.

So if a developer thinks this is a streaming or delayed-fetch API — because IEnumerable<T> can be — they're wrong. It’s just a preloaded list.

4. The Real Danger: Confusion and Redundant Work

Because the return type hides the fact that the data is already materialized, consumers often:

var users = (await repo.GetUsersAsync()).ToList(); // unnecessary!

This results in a copy of a list that's already a list.

Worse, if the internal repo implementation is ever refactored to yield from a generator, the caller’s .ToList() could re-execute database queries (in a non-buffered scenario).

Clearer Alternatives

To avoid these issues:

Return IReadOnlyList<T> to make it explicit that the result is fully realized.
Return IAsyncEnumerable<T> if you want streaming, lazy loading, or pipelining behavior.

Awaiting the Task.CompletedTask?

Damiaan — Mon, 26 May 2025 13:55:31 +0000

After I saw a colleague struggling with Task.CompletedTask, I thought I might be worth sharing our learning.

What is the Task.CompletedTask?

The Task.CompletedTask is a property on the Task class that returns a task that has already completed successfully, as the Status property will contain RanToCompletion.

In a sense, Task.CompletedTask is conceptually similar to Task.FromResult but for void returns. Both are used to create tasks that are done executing. One returns a value, the other doesn't.

When to use Task.Completed

It's useful when you have a Task return type in a method and you need to return without actually doing any asynchronous work.

Consider using the 'await' operator

My best guess is you have warning CS1998
Let's see what it says:

This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.

This is where programmers think they need to follow the advice from the warning. And they are trying to add more stuff to the solution trying to resolve the issue. When they come up with await Task.CompletedTask; the warning will disappear.

Is adding await Task.CompletedTask the right solution?

Let's take a step back.

Having an asyncmethod will add a state machine to your method. This will involve a slight (unnoticably) overhead.

Here is a c# method

public async Task M() 
{  
    return;        
}

When compilation is done, there will be a new method in your class trying to handle any await.

private void MoveNext()
{
    int num = <>1__state;
    try
    {
    }
    catch (Exception exception)
    {
        <>1__state = -2;
        <>t__builder.SetException(exception);
        return;
    }
    <>1__state = -2;
    <>t__builder.SetResult();
}

Replacing the return with await Task.CompletedTask converts the MoveNext() generated method to a beast.

private void MoveNext()
        {
            int num = <>1__state;
            try
            {
                TaskAwaiter awaiter;
                if (num != 0)
                {
                    awaiter = Task.CompletedTask.GetAwaiter();
                    if (!awaiter.IsCompleted)
                    {
                        num = (<>1__state = 0);
                        <>u__1 = awaiter;
                        <M>d__0 stateMachine = this;
                        <>t__builder.AwaitUnsafeOnCompleted(ref awaiter, ref stateMachine);
                        return;
                    }
                }
                else
                {
                    awaiter = <>u__1;
                    <>u__1 = default(TaskAwaiter);
                    num = (<>1__state = -1);
                }
                awaiter.GetResult();
            }
            catch (Exception exception)
            {
                <>1__state = -2;
                <>t__builder.SetException(exception);
                return;
            }
            <>1__state = -2;
            <>t__builder.SetResult();
        }

Look at these two lines:

awaiter = Task.CompletedTask.GetAwaiter();
if (!awaiter.IsCompleted) { ... }

We already learned that the Task.CompletedTask is a property that is already completed. So the compiler will be checking for completion of something that is already completed.

So adding in the await Task.Completed task is adding unnecessary asynchronous overhead.
Although the performance hit might be minimal, it's still an unnecessary context switch and state machine generation, which could be avoided.

On top of that it can be misleading to other developers reading your code. Seeing await typically suggests there is an asynchronous operation occurring, but in this case, it does not.

How to resolve warning CS1998

If there's no actual asynchronous work, consider

removing the async and
returning a completed task directly without await:

public Task SomeMethod()
{
    // Some code here...

    return Task.CompletedTask;
}

This avoids the overhead associated with async and await and is more efficient and clear.

While await Task.CompletedTask; is not inherently "bad", it's unnecessary and can be avoided. It's typically better to return Task.CompletedTask directly when no asynchronous operation is required.

DEV Community: Damiaan