[Proposal] Sync-async method binding

[ShadedBlink]

For the long time since the introduction of async methods we have to write synchronous overloads for asynchronous methods to support both workflows. However it means that we have to write double amount of the code which differs only by await keyword.
Example:

public class Foo {
    void Write(Stream stream)
    {
        stream.Write(new byte[] { 0 });
    }
    async Task WriteAsync(Stream stream, CancellationToken cancellationToken)
    {
        await stream.WriteAsync(new byte[] { 0 }, cancellationToken);
    }
}

These methods almost always have to be almost same except awaiting method(blocking for synchronous, await for asynchronous). This proposal's purpose is to eradicate this code duplication by enforcing method binding. Forementioned methods are always logically bound, i.e. when you use stream.Read() you expect that stream.ReadAsync() should do exactly the same, just in non-blocking way. This assumption allows us to make compilation of synchronous methods dependent on their asynchronous counterpart.
Proposal source code example, it compiles in exactly same code as in example before:

[AttributeUsage(AttributeTargets.Method)]
public class SyncAttribute : Attribute
{
    public string NameOverride { get; set; }
}

[AttributeUsage(AttributeTargets.Parameter)]
public class AsyncOnlyAttribute : Attribute { }

public class Foo {
    [Sync]
    async Task WriteAsync(Stream stream, [AsyncOnly] CancellationToken cancellationToken)
    {
        await stream.WriteAsync(new byte[] { 0 }, cancellationToken);
    }
}

At the moment proposal is expected to perform at MSIL compile-time so it's mostly C#-limited feature. Later it can be moved to JIT compile-time, so we can reduce our binary size as well since only one instance of the bound methods would be present in a binary.

When project is compiled and compiler encounters method Foo.WriteAsync(), it checks the existence of Sync attribute. Since it is present, compiler emits a synchronous counterpart of WriteAsync(), where name is replaced by SyncAttribute.NameOverride or initial method's name without Async suffix.
Return type is decided by the return type of initial method: if task-like type is typed(Task<T>, ValueTask<T> and etc), then return type is T, otherwise(Task, ValueTask and etc) - void.
Any parameter marked with AsyncOnly(we can introduce the SyncOnly counterpart as well, but I don't see any reason for it now) is omitted from synchronous method. The order of parameters is saved as is.
For the all method's code compiler should apply asynchronous method's rules, i.e. no locks with awaits, no byref variables and etc. Even though it is considered that we will have a synchronous counterpart, rules should be the same since methods are expected to have same logical behaviour.
When compiler encounters an await in the code, it uses it as is in async case, but for the sync case it should check if called method(stream.WriteAsync() in forementioned case) is marked with Sync attribute. If the attribute is present, then compiler automatically replaces this call with synchronous counterpart, all parameters are mapped from initial async call. In our case cancellationToken would be omitted from synchronous call since it would be marked AsyncOnly in called method. If an expession was used as a parameter for cancellationToken, i.e. stream.WriteAsync(arr, LogAndReturn(cancellationToken)), then LogAndReturn() is not called in synchronous counterpart, i.e. behaviour is alike with ConditionalAttribute.
If awaited method is not marked with Sync, then compiler throws an error: "Method is not bound with a synchronous counterpart".
Compiler should ensure that no AsyncOnly parameters are used in synchronous context.

In case when we have to use different logic for sync and async cases, we can use next approach:

    [Sync]
    async Task WriteAsync(Stream stream, [AsyncOnly] CancellationToken cancellationToken)
    {
        async {
            Console.WriteLine("Async method is called!");
            await stream.WriteAsync(new byte[] { 0 }, cancellationToken);
        }
        sync {
            stream.Write(new byte[] { 0 });
        }
    }

async and sync keywords placed in method body are just a syntax sugar that can be used to mark scope with corresponding rules, i.e. like unsafe. When compiler compiles WriteAsync() method, for the async counterpart it will ignore all sync blocks and vice versa. When inside of a sync or async block, compiler ignores any need for Sync attribute mapping of awaited methods and just compiles this code as is.

[CyrusNajmabadi]

Having the presence of an attribute be used to generator code that is based off of user code is exactly the realm of a source generator.

You should be able to do this today without needing a language change or any additional features from the compiler :-)

[CyrusNajmabadi]

This proposal is not about a some T4-makefast packed code generator, it is a deduplicator.

Yes. But why does it matter if that deduplicator is provided by us, in language, 6-10 years from now. Versus being provided as a source generator tomorrow, that can be used by any down level compiler from the past 5 years on any language version?

SGs solve the problem today. There is no downside to them. People using them would still use the attributes just as you specified. So the only difference is that you are insisting that the solution come from us, rather than from the community.

[ShadedBlink]

@CyrusNajmabadi , as I already noted it in proposal, given implementation could allow us to cut our binary sizes by omitting all sync-versions of methods. For all other cases where today we decided to support only async versions of methods like HttpClient we will provide their synchronous counterparts almost out-of-the-box with zero-cost development support. While source generators may allow us to duplicate code, they are unable to cut binary sizes.

At the moment proposal is expected to perform at MSIL compile-time so it's mostly C#-limited feature. Later it can be moved to JIT compile-time, so we can reduce our binary size as well since only one instance of the bound methods would be present in a binary.

Also this proposal may be auto-enabled for all new projects out-of-the-box, i.e. if async method uses only sync-bound methods and named with *Async suffix, then we automatically compile it as sync-bound. Thus almost all of the user projects are gonna become sync-bound, since the cases with native async implementation overriding are too rare. I mean that in most cases user just uses dotnet libraries with core async methods, which are already marked by sync-bound attribute. Since all user's methods are using sync-bound methods, then we are free to compile them as sync-bound as well. Then all projects that are using given project are compiled as sync-bound as well.

[CyrusNajmabadi]

if async method uses only sync-bound methods and named with *Async suffix, then we automatically compile it as sync-bound

I can't see us ever doing this. If you exposed an async method, then we're going to emit an async method. Not doing so would mean emitting something entirely different from what you wrote.

It would then also be a breaking change for you to actually do anything truly async in the method as doing that would now mean that the emitted code switched from sync to async. This would then break all downstream libraries compiled against you as they would be calling against a method that no longer exists.

[bbarry]

@roji had this awesome nuget a few years ago: https://github.com/roji/AsyncRewriter and a decent discussion in one of the issues roji/AsyncRewriter#13

[roji]

@bbarry thanks for the mention, I had almost forgotten I did this thing back in the day (before source generators even existed...).

FWIW I fully agree with @CyrusNajmabadi that this makes a lot of sense as a source generator, rather than in the language. Re the code size reduction, I may be missing something, but the .NET story for keeping binary size down is trimming. So even if a source generator adds code during compilation, the linker can then remove anything that isn't actually used in the application. So I'm not sure what the problem here is.

[En3Tho]

Well nobody really has to always support both workflows. Many modern apis are currently either sync or async and not both. There are many old ones and Stream is a an example of that, yes, but honestly it is at the same time a terrible example to base language features on.

Every now and then you have to override a ton of stuff and think of "what if there was a better way? If only language could so this and that...". But language should not cover pain points of old api designs. It should instead open possibilities to create new ones which are both faster and more ergonomic... Until they're legacy again.

Honestly I don't think you're making these stream overrides every day. But if you do there is a Copilot.