UDL support for async methods

[AArnott]

The User's Guide only tells how to define async functions when using attributes. How can I define async functions when using the .udl file?

[gmulhearn-anonyome]

WIthin the docs currently:

Note that currently async functions are only supported by proc-macros, if you require UDL support please file a bug.

https://mozilla.github.io/uniffi-rs/futures.html

[AArnott]

Ah, quite right. Well then, here's the bug. :)

My 'need' is based on consuming the C# generator, which doesn't support the attribute syntax at all.

[bendk]

Does the C# generate support async in general? I think that's also an issue.

But I do think we should support async methods in the UDL. I was thinking about this the other day and realized I don't like the standard method for this:

 Promise<Foo> read_foo();

... since that implies that any type could be wrapped in a promise including arguments. We currently have no generalized method of moving a Future across the FFI and I don't think that's coming anytime soon. It would also require extra work to parse. Instead, I think we should use an attribute like this:

[Async] 
Foo read_foo();

What do others think?

[mhammond]

I was thinking about this the other day and realized I don't like the standard method for this:

 Promise<Foo> read_foo();

... since that implies that any type could be wrapped in a promise including arguments.

hrm - is there ever a future where we do support this?

We currently have no generalized method of moving a Future across the FFI and I don't think that's coming anytime soon. It would also require extra work to parse. Instead, I think we should use an attribute like this:

[Async] 
Foo read_foo();

What do others think?

I'm fine with that TBH, and always assumed that's what we'd do - I forgot about Promise<> - although if we ever did want to support promises/futures as args then the earlier option sounds more extensible.

(I guess it's also not an either-or option - there's no reason we couldn't add support for Promise<> and deprecate the attribute later, but I suspect it's not going to happen in reality)

[AArnott]

Does the C# generate support async in general? I think that's also an issue.

I don't suppose it could, since it doesn't support attributes and that's the only way to do async today.
Perhaps the more interesting question is whether the C# generator would pick up async support more quickly if there was UDL support for it than it would pick up attribute syntax support, including async.
@NordSecurity, what do you think?

[bendk]

hrm - is there ever a future where we do support this?

I think that could be very nice, although we would need a lot of other things in place, like the ability for foreign code to define a promise value. Maybe once we do async callback interface methods and more on traits we could look at it.

Also, and I'm not sure of this, but don't some of the foreign languages distinguish between an async function and a function that returns a Future? I think Swift does. So maybe we would want to support both Promise<> and [Async] to differentiate the two things (and also do that on the proc-macros).

[bendk]

On a more practical level, I'm currently working towards adding support for async callback interface methods. That's going to require some async_trait style workarounds at the Rust level. I think once that's done it would be a good time to add UDL async support.