Proposal: ITask and ITask<T> interfaces

[Joy-less]

Currently, it can be very tricky to work with tasks in reflection. For example, if you have a Task<T> cast to an object, there is no way to get the result without reflection. Additionally, there is no way to handle Task and ValueTask at the same time. An ITask interface could solve both problems.

Before

object? obj = GetObject();
if (obj is Task task) {
    if (task.GetType().IsGenericType) {
        object? result = task.GetType().GetProperty(nameof(Task<object>.Result))!.GetValue(task);
    }
}
else if (obj is ValueTask valueTask) {
    if (valueTask.GetType().IsGenericType) {
        object? result = valueTask.GetType().GetProperty(nameof(ValueTask<object>.Result))!.GetValue(valueTask);
    }
}

After

object? obj = GetObject();
if (obj is ITask task) {
    if (task.TryGetResult(out object? result)) {
        // ...
    }
}

A proposal already exists to make Task covariant, meaning Task<string> could be cast to Task<object>. However, this proposal would also handle ValueTask, and any other type of Task added in the future.

ITask would look something like this:

namespace System.Threading.Tasks;

public interface ITask {
    public bool TryGetResult(out object? result);
    public bool HasResult();
    public TaskAwaiter GetAwaiter();
}

public interface ITask<T> : ITask {
    public T GetResult();
    public new TaskAwaiter<T> GetAwaiter();
}

Both Task and ValueTask would inherit from ITask. Additionally, asynchronous functions would be able to return ITask instead of Task or ValueTask.

[Clockwork-Muse]

.... I think I'm immediately concerned about any code where you're handling arbitrary object types like that. The example chosen feels like it would emerge from a design smell of some sort, and would be better handled in some other fashion to begin with.

Does this represent some of your real-world code? If so, what is the particular problem you're trying to solve by resolving arbitrary object types this way?

[Joy-less]

It's used in my remote-procedure library Rem Send. One machine sends the other machine the name of a remote procedure and some serialised arguments, then the other machine finds the method using reflection (verifying it's got an attribute) and calls it dynamically. If the method returns a Task, it should be awaited before the result is returned to the other machine.

This allows code like this:

[Rem(RemAccess.Any)]
public async Task<int> WaitAndGetNumberRem() {
    await Task.Delay(TimeSpan.FromSeconds(1));
    return 5;
}

int Number = await Rem(1, () => GetNumberRem()); // 1 is the server's peer ID

[Clockwork-Muse]

then the other machine finds the method using reflection (verifying it's got an attribute) and calls it dynamically.

Yeah, don't do this if you can avoid it.
For any RPC library, you really want to look into source generators.

Even if you can't use source generators for whatever reason, the better option would be to generate parser stubs on initialization, that end up being called directly.

That said....

• Godot already has RPC functionality built-in, is there an additional problem you're trying to solve? Or you want it to be able to interact with non-Godot clients/servers?
• I'd actually look into integrating one of the well-known RPC server/client libraries instead (ie, gRPC) into godot instead. Don't implement your own server/wire protocol if you can avoid it, and it also allows for wider interoperability.
• Given the likelihood you'll need to work with other threads, you might want to just make everything async anyways.

[Joy-less]

For any RPC library, you really want to look into source generators.

I already looked into source generators and would use them if I could (I spent hours trying). However, they are far too complex and undocumented for me to use at the moment (especially with Godot's NuGet setup). Maybe in the future.

Godot already has RPC functionality built-in, is there an additional problem you're trying to solve? Or you want it to be able to interact with non-Godot clients/servers?

Godot's RPC implementation does not support a number of features, including returning values, which is directly relevant to this proposal.

I'd actually look into integrating one of the well-known RPC server/client libraries instead (ie, gRPC) into godot instead. Don't implement your own server/wire protocol if you can avoid it, and it also allows for wider interoperability.

This is kind of a tangent, but gRPC does not solve the same problem. My library uses MemoryPack instead of protobuf, my library is closer to Godot's RPCs (which are used under the hood), my library uses expression trees (meaning you can Ctrl + LMB in your IDE to find the method implementation), and a number of other differences.

Given the likelihood you'll need to work with other threads, you might want to just make everything async anyways.

The method is called using reflection meaning you can't just 'make everything async' since it returns an object, which is the issue in this proposal.

[Clockwork-Muse]

The method is called using reflection meaning you can't just 'make everything async' since it returns an object, which is the issue in this proposal.

What I meant was that, since these are going to be RPC calls, you should just require them to be Task/Task<Whatever>, period.

That said, having looked through the general capabilities in the engine, I'm relatively certain you should be able to generate rpc stubs and weave returns via callbacks either at init-time or via @tool scripts at build/editor time.

[huoyaoyuan]

The example is misusing ValueTask. It requires extra caution, for example Result shouldn't be used when not completed, and it should not be boxed to avoid double usage which is invalid.

Since ValueTask and Task can wrap the other with or without overhead, the correct approach is to accept ValueTask or Task only base on the usage pattern.

[Joy-less]

I think ITask would be a cleaner and more performant solution than checking for ValueTask and converting to Task. This proposal would mirror the way Array and List inherit from IList, even though you could wrap the Array in a List. By having ITask, you can check for any task that behaves like a Task, which also provides future-proofing (let's say .NET adds a ReusableTask or Task<T1, T2> or something).

[huoyaoyuan]

It's the opposite, Task should be wrapped into ValueTask if it's invoked only once. It's nearly zero-cost.

let's say .NET adds a ReusableTask

It's IValueTaskSource, which is also wrapped in ValueTask.