Possibly reducing boilerplate.

[Swoorup]

Thanks for this awesome crate.

Instead of init2, init or try_* or even pin_* variant, is it possible for the macro to just generate a particular variant? I think you usually tend to just just one kind of constructor throughout the codebase?

#[dynify::dynify(init2)]
trait AsyncRead { // By default, another trait prefixed with `Dyn` is generated.
    async fn read_to_string(&mut self) -> String;
}


async fn dynamic_dispatch(reader: &mut dyn DynAsyncRead) {
    let content = reader.read_to_string().await;

    /*  The above will do behind the scenes this.
    let mut stack = [MaybeUninit::<u8>::uninit(); 16];
    let mut heap = Vec::<MaybeUninit<u8>>::new();
    // Initialize trait objects on the stack if not too large, otherwise on the heap.
    let fut = reader.read_to_string().init2(&mut stack, &mut heap); 
    */
}

[loichyan]

Thanks for the issue!

I don't think it's possible for the current containers, except for Box¹. When using buffers, whether on the stack or on the heap, we need to manually pass a mutable reference, and these references cannot be obtained during macro expansion. In the Box case, we require "self-contained" containers: that is, we can create such a container (without external arguments), allocate a trait object in it, and return that container. There is a crate, stackfuture, that can do similar things. I planned to add similar containers but found that achieving this requires the nightly ptr_metadata feature for full compatibility with the current codebase of dynify².

On the other hand, doing this could lead to some drawbacks for dynify:

1. We would lose some runtime flexibility since the container would be fixed. But since you explicitly opted for this, it doesn't seem relevant.
2. Even if we have the said containers, we lose the ability to reuse them. This means there would still be repeated allocations in loops (specifically for async iterators) since each call to an async method returns a container created by itself.

Footnotes

1. Container is where a Future is allocated. ↩

2. That said, it's possible to implement such containers for a particular trait in stable Rust. In most cases, addding for Future is sufficient. ↩

[loichyan]

That said, I'm going to research a bit further in the near future for the said self-contained containers (maybe for Future only, since I want them to work on stable Rust). The final solution may look like this:

#[dynify::dynify(strategy = "boxed")] // "stacked" or "smallvec"
trait AsyncRead {
    async fn read_to_string(&mut self) -> String;
    // This would return `Box<dyn Future>`, `Stack<dyn Future>`,
    // or `SmallVec<dyn Future>` depending on the strategy.
}