Async Interfaces feature request please.

[AlexisColes]

Hi there,

I want to be able to implement the same shared interface on both the client and server but on the client I want to implement the interface with an async signature and on the server I want to implement the sync signature.

Would it be possible to do something like the following:

public interface IFoo
{
    int Get(int i);
}

public class Foo : Async<IFoo>
{
   public async Task<int> Get(int i)
   {
         ....
   }
}

I realize that this probably isn't as easy as I am making it sound but I am really just looking for a way to define a contract which the compiler could check has been implemented in either a sync or an async fashion.

[Mafii]

So all return types should automatically replaced with their task (default task implementation) equivalent?

Or should that be done by hand, and verified by the compiler?

I see the use of it, great idea. I just don't remember ever wanting to have this feature.

[jnm2]

So you're asking for the compiler to emit and use an IAsyncFoo interface when it sees Async<IFoo>? What if Async<> is a class you already define?

[AlexisColes]

@jnm2 I am not attached to the semantics here, hopefully someone with a much deeper understanding of the language could suggest a much better way of declaring this than I have suggested. But it would probably be in a different namespace?

@Mafii yes if they are just automatically replaced with their task equivalent that would probably cover all the use-cases I have in mind. But if there could be some more fine grain control over this so much the better.

I suppose what I really want to do is to dynamically generate a proxy class based on an interface, all our request code is pretty boiler plate and could be auto generated. The best I can do at the moment would be something that implements

    public interface IMyDynamicClient<T>
    {
        T Channel { get; }
    }

But if I wanted all my calls to be async, I need someway of turning T into an asyn<T> or I have to define the contract twice :(

[HaloFour]

The syntax suggested I think would be very confusing. The class doesn't implement IFoo nor can a generic container like Async<T> do something like create new members based on an existing interface.

I think that something like this could fall under the mythical source generator umbrella. You could decorate the class with an attribute that specifies that it "pseudo-implements" the interface in an async manner and also specify what kind of strategy to use when generating the async methods. The question there would be what would the source generator actually generate given that it would fall on your class to actually provide the implementation of those methods. Only thing I could think of would be for the generator to emit a new async-flavor of the interface and then have your class implement it:

You would write:

[AsyncImplementation(typeof(IFoo), WithCancellationToken = true, WithAsyncSuffix = true)]
public partial class Foo
{
}

And the generator could emit:

public partial class Foo : Foo.IAsyncFoo
{
    public interface IAsyncFoo
    {
        Task<int> GetAsync(int i, CancellationToken cancellationToken);
    }
}

And then you'd have to amend your code to implement IAsyncFoo.GetAsync in order to compile:

[AsyncImplementation(typeof(IFoo), WithCancellationToken = true, WithAsyncSuffix = true)]
public partial class Foo
{
    public async Task<int> GetAsync(int i, CancellationToken cancellationToken)
    {
        // do stuff here
    }
}

That would allow the generator to provide options to allow different strategies of code generation.

I wonder if maybe the source generator proposal could consider additional syntax that would allow generators to emit that a partial class must implement certain members. (#753 would seemingly handle that nicely.)

[svick]

What is the point? Couldn't you just use Task<T> everywhere? The implementation of a Task<T> method can still be be synchronous (likely using Task.FromResult()).

[MkazemAkhgary]

or you can move async part into separate method. for example some thing like async Task FillBuffer and rest of your methods normally implement IFoo and do rest of job synchronously.

[alrz]

@svick: The implementation of a Task method can still be be synchronous (likely using Task.FromResult()).

Plus, if you don't want to implement it in every class, default interface implementations might help,

interface IFoo
{
    // implement each method in terms of the other
    // then you only need to implement either of those
    int Get(int i) { ... }
    Task<int> GetAsync(int i) { ... }
}

Which is a terrible idea.

[CyrusNajmabadi]

Isn't this what libraries like protobuffs are for? You supply an interface stating your protocol, and you get the appropriate client and server code gened for you do all this work.

[paulirwin]

FWIW, TypeScript has something like this:

// Same property names, but make the value a promise instead of a concrete one
type Deferred<T> = {
    [P in keyof T]: Promise<T[P]>;
};

If this were done in a similar vein to TypeScript, I might get behind it because that could open the door to other TypeScript equivalents like Readonly<T> and (perhaps with interface methods) Proxify<T>. But the differences between dynamic and static languages here causes some mental gymnastics trying to think about how to express this in a static way.

[Pzixel]

@paulirwin

But the differences between dynamic and static languages here causes some mental gymnastics trying to think about how to express this in a static way.

Codegen FTW :) I actually have done something similar: https://github.com/Pzixel/RemoteClient.Roslyn

Works just fine. I agree that it would be nice to have it in the language itself, but as you said it's not really convinient for statically typed one.

[paulirwin]

@Pzixel Rather than a "traditional" .NET code generation approach, I'd much rather see this be possible a la the proposed C++ constexpr compile-time metaprogramming.

Using the IFoo example from OP, here's some pseudo-C# gratuitously re-using the constexpr keyword and syntax from the C++ compile-time programming proposal:

public interface IFooAsync {
    constexpr {
        ConvertToAsync<IFoo>();
    }
}

Which would generate:

public interface IFooAsync {
    Task<int> GetAsync(int i);
}

Of course in this trivial example it is less code to just write it out yourself, but perhaps this could be achieved via some decorator attribute, i.e. [ConvertToAsync(typeof(IFoo))];

The ConvertToAsync method would look something like (prototype example, only handling Task<T>):

public static constexpr ConvertToAsync<T>() where T : class {
    foreach (var method in typeof(T).GetMethods()) {
        // i.e. check to make sure method isn't already async, handle void -> Task, etc. etc.
        var returnType = typeof(Task<>).MakeGenericType(method.ReturnType);
        var name = $"{method.Name}Async";
        var parameters = method.GetParameters(); // transform somehow?
        -> {
            $returnType$ $name$($parameters$);
        }
    }
}

However, I don't know how this would handle scenarios like circular references. But it's fun to think about.

[HaloFour]

@paulirwin

Sounds like a very similar approach to source generators, except with a lot of additional syntax changes directly to the language. I don't see how that would work in a compiled form, e.g. a helper assembly you can acquire via NuGet?

[paulirwin]

@HaloFour It is very similar to T4, but can be used inline in your source and runs through the same compiler as the rest of your code so you get built-in reflection and type safety at compile time. Think of it as a better alternative to macros. I would imagine you could produce constexpr functions and export those in an assembly to be consumed by others, at the referencing assembly's compile time. constexpr functions are statically guaranteed to be able to run at compile time. i.e. public static constexpr int Add(int x, int y) => x + y; could yield the literal value 5 into your code when called via const int x = Add(2, 3); so it is not evaluated at runtime. Obviously this is a much larger discussion than async interfaces, so I don't want to derail this by going into detail, nor do I want the burden of opening up an issue for this feature myself. I'm just proposing it as one possible way of implementing this feature, and most likely opening the door to solving a number of other features at the same time, without having to add one-off features like this to the language itself. That was the motivation for Herb Sutter's excellent C++ Metaclasses proposal to allow for things like proper interfaces and record types without having to add them as language features.

Here's an alternative, more type-safe version of that method with less syntax changes needed, just the constexpr modifier:

public static constexpr IEnumerable<InterfaceMethod> ConvertToAsync<T>() where T : class {
    foreach (var method in typeof(T).GetMethods()) {
        // i.e. check to make sure method isn't already async, handle void -> Task, etc. etc.
        var returnType = typeof(Task<>).MakeGenericType(method.ReturnType);
        var name = $"{method.Name}Async";
        var parameters = method.GetParameters();
        
        yield return new InterfaceMethod(returnType, name, parameters);
    }
}

[HaloFour]

@paulirwin

By "source generators" I'm not referring to the existing T4 methods for generating source within a project, I am referring specifically to the proposal here to integrate source generation into analyzers so that they are a part of the compilation pipeline. Those "generators" would be referenced into a project like analyzers are today, via NuGet, and would automatically integrate into the editor experience.

I included some source above as to what that might look like to a consumer when implementing a class. But it could also be applied to interfaces directly, e.g.:

[ConvertToAsync(typeof(IFoo))]
public partial interface IFooAsync { }

And a generator could identify all marked interfaces and emit source for the members:

// generated
public partial interface IFooAsync
{
    Task<int> GetAsync(int i, CancellationToken cancellationToken);
}

That would be completely seamless to the developer (they could view the generated source, but they don't have to worry about maintaining it, even if IFoo changes).

As a championed proposal this approach seems much more likely to find adoption. The issue with it seems to be the amount of load it puts on the editor to provide a good experience given that virtually any change to the source could have a sweeping impact.

Your approach is interesting but it involves a significant amount of changes to the language and would likely suffer from the same problem that generators face in that the editor experience would be very difficult to get right.