Add Then method to Task-like types

[jmarolf]

API Proposal

namespace System.Threading.Tasks
{
    public class Task<TResult> : Task
    {
+       public Task<TNewResult> Then<TNewResult>(Func<TResult, TNewResult> selector);
+       public Task<TNewResult> Then<TNewResult, TArg>(Func<TResult, TNewResult> selector, TArg);
    }

    public readonly struct ValueTask<TResult> : IEquatable<ValueTask<TResult>>
    {
+       public ValueTask<TNewResult> Then<TNewResult>(Func<TResult, TNewResult> selector);
+       public ValueTask<TNewResult> Then<TNewResult, TArg>(Func<TResult, TNewResult> selector, TArg);
    }
}

The functions given to these Then methods are only called if Task.IsCompletedSuccessfully would be true. Otherwise, a Task with the same cancellation state and exception information is returned, but of type Task<TNewResult> instead of Task<TResult>.

API Usage

async Task M(){
    string text = await File.ReadAllTextAsync(path).Then(static text => text.ReplaceLineEndings());
}

Task<string> M(){
    return File.ReadAllTextAsync(path).Then(static text => text.ReplaceLineEndings());
}

Background and motivation

Method chaining is a very common way to manipulate data.

void M(){
    string text = File.ReadAllText(path).ReplaceLineEndings();
}

and today expressions are one of the main ways in which data gets manipulated in .NET with C# continuing to make it easier to "expression-ify" things where it makes sense to do so.

Unfortunately, once async comes into the picture you need to wrap things in parenthesis in order for the associativity to keep working the way the developer wants and we need to be in an async method.

async Task M(){ // need to be async method
    string text = (await File.ReadAllTextAsync(path)).ReplaceLineEndings(); // must wrap all awaits in parenthesis or have on separate line
}

You can try and solve some of this with the ContinueWith methods but they have some usability issues.

Lets say we wanted to write our own extension method with a signature like this

public static Task<TNewResult> Then<TResult, TNewResult>(this Task<TResult> task, Func<TResult, TNewResult> selector)

a naïve implementation may look like this

public static Task<TNewResult> Then<TResult, TNewResult>(this Task<TResult> task, Func<TResult, TNewResult> selector)
{
    return task.ContinueWith(ContinuationFunction, state: (object?)selector);
    static TNewResult ContinuationFunction(Task<TResult> task, object? state)
    {
        if (task.IsCompletedSuccessfully && state is not null)
        {
            var selector = (Func<TResult, TNewResult>)state;
            return selector(task.Result);
        }

        // this helper needs to account for canceled tasks and exceptions
        throw new InvalidOperationException();
    }
}

A few problems with this:

1. It needs to handle cancellation and exceptions

This is not impossible to do just tricky. It is unfortunate that this is necessary. In a world where folks are awaiting Tasks, cancellation and exceptions are going to be thrown at the call site of the await. Handling these cases shouldn't be required and it would be nice to have a method that is only called if the task completes successfully instead of forcing this concern on developers using the ContinueWith api.

2. You cannot pass in args without boxing

Since ContinueWith only excepts object? for its state type you cannot do something like this without boxing:

namespace MyNamsspace
{
    public enum LineEndingKind
    {
        CrLf,
        Lf
    }

    public class Program
    {
        public static Task<string> M(string path, LineEndingKind lineEndingKind)
        {
            // there exists some overload of ReplaceLineEndings that accepts a LineEndingKind 
            return File.ReadAllTextAsync(path).Then(static (text, kind) => text.ReplaceLineEndings(kind), lineEndingKind);
        }
    }
}

namespace System.Threading.Tasks
{
    public static class TaskExtensions
    {
        public static Task<TNewResult> Then<TResult, TArg, TNewResult>(this Task<TResult> task, Func<TResult, TArg, TNewResult> selector, TArg arg)
        {
            return task.ContinueWith(ContinuationFunction, state: (object?)(selector, arg)); // if arg is a struct we are boxing it here
            static TNewResult ContinuationFunction(Task<TResult> task, object? state)
            {
                if (task.IsCompletedSuccessfully && state is not null)
                {
                    var (selector, arg) = ((Func<TResult, TArg, TNewResult>, TArg))state;
                    return selector(task.Result, arg);
                }

                // this helper needs to account for cancelled tasks and exceptions
                throw new InvalidOperationException();
            }
        }
    }
}

3. This approach cannot be taken on ValueTask

If you wanted to write a similar helper for ValueTask you could do

public static async ValueTask<TNewResult> Then<TResult, TNewResult>(this ValueTask<TResult> valueTask, Func<TResult, TNewResult> selector)
{
    return await valueTask.AsTask().Then(selector);
}

but this:

1. always converts the ValueTask to a Task, negating the point of ValueTask in many cases
2. awaits the Task, which may not be a safe thing to do (should it be configured? if so how?)

Alternative Designs

Name

Then is the name take by many other constructs of this type in other languages, but I could see someone arguing for Select.

namespace System.Threading.Tasks
{
    public class Task<TResult> : Task
    {
+       public Task<TNewResult> Select<TNewResult>(Func<TResult, TNewResult> selector);
+       public Task<TNewResult> Select<TNewResult, TArg>(Func<TResult, TNewResult> selector, TArg);
    }

    public readonly struct ValueTask<TResult> : IEquatable<ValueTask<TResult>>
    {
+       public ValueTask<TNewResult> Select<TNewResult>(Func<TResult, TNewResult> selector);
+       public ValueTask<TNewResult> Select<TNewResult, TArg>(Func<TResult, TNewResult> selector, TArg);
    }
}

As this has a similar "transform a deferred value" feel that linq has.

Interaction with enumeration

You could also imagine an extension method like this being considered:

public static IEnumerable<Task<TNewResult>> Then<TResult, TArg, TNewResult>(this IEnumerable<Task<TResult>> source, Func<TResult, TArg, TNewResult> selector, TArg arg)
{
    foreach (var item in source)
    {
        yield return item.Then(selector, arg);
    }
}

But once the core Then method exists writing this extension is trivial enough to get right that I do not think it is worth including.

One thing that would be hard to get right is something like this:

public static async IAsyncEnumerable<TNewResult> Then<TResult, TArg, TNewResult>(this IAsyncEnumerable<TResult> source, Func<TResult, TArg, TNewResult> selector, TArg arg)
{
    await foreach (var item in source) // awaiting may not be safe here
    {
        yield return selector(item, arg);
    }
}

since it would require us to await the move next which may not be a safe thing to do without configuring the task. However, at this point we are just talking about implementing the Select linq method for IAsyncEnumerable types. If we ever do that, we can decide on the correct way such and enumerable would be written taking ConfigureAwait into account. Seems safe to punt on this concern for now.

Risks

My assumption is that Task and ValueTask are some of the most used types in .NET so modifying them in any way carries a great risk. I think that the implementation here could just be extension methods on these types with internal access so they can be implemented efficiently but if they do actually need to exist on the types themselves there is the concern of increasing the size of these types at all as thay are so common it could decrease .NET performance by allocating more resources.

[jmarolf]

originally posted this as a discussion to make sure there were no obvious holes here. I've now moved this to #76839