auto optional CancellationToken propagation

[JustNrik]

Basically, automatically propagate all cancellation tokens that are optional arguments.

Example

public async Task DoSomethingAsync(object[] args, CancellationToken token = default)
{
    DoStuff(args);
    await DoOtherStuffAsync();
}

public async Task DoOtherStuffAsync(CancellationToken token = default)
{
    token.ThrowIfCancellationRequested();
    SomeOtherStuff();
    await MoreStuffAsync();
}

public async Task MoreStuffAsync(CancellationToken token = default)
{
    token.ThrowIfCancellationRequested();
    await EvenSomeMoreStuff();
}

On every Task-returning method that accepts an optional cancellation token, if not provided explicitly, it will automatically be inserted from the current method, so it would be compiled into:

public async Task DoSomethingAsync(object[] args, CancellationToken token = default)
{
    DoStuff(args);
    await DoOtherStuffAsync(token);
}

public async Task DoOtherStuffAsync(CancellationToken token = default)
{
    token.ThrowIfCancellationRequested();
    SomeOtherStuff();
    await MoreStuffAsync(token);
}

public async Task MoreStuffAsync(CancellationToken token = default)
{
    token.ThrowIfCancellationRequested();
    await EvenSomeMoreStuff(token);
}

This may reduce the verbosity in projects where tokens are passed everywhere, this feature could also be made thru attributes, something like [CallerCancellationToken]

[HaloFour]

See: #6300

It's a more general feature, but CancellationToken was called out as one of the potential motivating use cases to consider it.

This may reduce the verbosity in projects where tokens are passed everywhere, this feature could also be made thru attributes, something like [CallerCancellationToken]

If the general feature doesn't come to pass, I could see this being a way to solve for CancellationToken specifically. I assume it would only automatically wire up the argument if exactly one CancellationToken variable was in scope, otherwise it would warn/error?

[JustNrik]

Pretty much, I guess the easiest way to implement this for the compiler team is probably doing it through an attribute or a keyword, though I'm more into attribute as you can provide them arguments such a variable name to resolve possible name conflicts, like calling an async method that, for some reason, takes 2 cancellation tokens and the one you want to pass implicitly has another name, which is niche but still falls into ambiguity.

In general I expect it to warn/error if it simply find it ambiguous to replace any token(s) as well as it should inform if it's not actually propagating anything so the end-user always knows if it'll behave as it should.

public async Task DoStuff([Propagate] CancellationToken token = default)
{
    await DoOtherStuff(); 
    /*
     * If DoOtherStuff has exactly 1 parameter that takes CancellationToken, then it's passed normally
     * If DoOtherStuff is parameterless, then the user will be informed that the token is not being propagated and you can remove the attribute, this way the user knows no method is actually using the token
     * If DoOtherStuff takes 2 or more parameters, and more than 1 of them turns out to be CancellationToken for... Reasons... then the behaviour could be the following:
     *   1) it would attempt to match by name, and error if it can't
     *   2) it would attempt to match by name, and warn the user as a name hasn't been set explicitly in the attribute
     *   3) it would just error so the user either sets a name to match in the attribute or passes the token explicitly
     */
}

[theunrepentantgeek]

Also #1332, which had a similar goal but also tried to address shortcomings with the Scala approach. (Disclosure: that issue was one of mine.)