finish_fn with .await (IntoFuture implementation for the builder)

[fomotoshi]

is it possible to implement IntoFuture for asynchronous function and make .await like .call()?

// now
let ret = fetch()
        .wallet(wallet.address)
        .chain(wallet.chain)
        .call()
        .await?;
        
 // after
 let ret = fetch()
        .wallet(wallet.address)
        .chain(wallet.chain)
        .await?;

[Veetaha]

Hi! It's definitely possible, but this requires boxing the future. That's why bon doesn't do this by default. You can implement IntoFuture for the builder manually though like this. The following code compiles and runs just fine. So if you are okay with taking a perf. hit with boxing the future, you can do it like this:

use std::future::{Future, IntoFuture};
use std::pin::Pin;

#[bon::builder]
async fn fetch(wallet: String, chain: String) -> String {
    format!("{wallet}:{chain}")
}

impl<S: fetch_builder::IsComplete + 'static> IntoFuture for FetchBuilder<S> {
    type Output = String;

    type IntoFuture = Pin<Box<dyn Future<Output = Self::Output> + Send>>;

    fn into_future(self) -> Self::IntoFuture {
        Box::pin(self.call())
    }
}

#[tokio::main]
async fn main() {
    // This works
    let ret = fetch()
        .wallet("wallet".to_owned())
        .chain("chain".to_owned())
        .call()
        .await;

    // and this works too
    let ret = fetch()
        .wallet("wallet".to_owned())
        .chain("chain".to_owned())
        .await;
}

If you want to enforce not using the call() method - you can make that method private with #[bon::builder(finish_fn(vis = ""))]

[fomotoshi]

@Veetaha You can use 'impl Future' nightly, is it possible to add this feature to experimental bon's features?

[Veetaha]

@ChzenChzen I'd like to avoid using nightly if possible especially for such a feature that has been unstable for 6 years yet still has unresolved questions with an unknown resolution ETA (rust-lang/rust#63063).

In this case, it's possible to have IntoFuture support using stable features with just boxing the future. So, We could have a syntax like the following requiring the user to spell Box to be explicit about an allocation:

#[builder(derive(IntoFuture(Box)))]
// ^ this produces this assoc type:
type IntoFuture = Pin<Box<dyn Future + Send + use<'lifetimes, 'from, 'all, 'input, 'params>>>

Studying the mechanics of #[async_trait] expansion should be very useful here.

To remove the Send bound we can follow async_trait's syntax with the ?Send syntax:

#[builder(derive(IntoFuture(Box, ?Send)))]
// ^ this produces this assoc type:
type IntoFuture = Pin<Box<dyn Future + use<'lifetimes, 'from, 'all, 'input, 'params>>>

If the time ever comes for impl Trait support in assoc type position to stabilize, we'll have a variant of this that doesn't allocate.