Does Rust's 1.85 async closures replace or compete with this library's usage of scoped futures?

[lsunsi]

I wanted to raise this conversation because I have limited understanding of how scoped futures works. We use diesel async a lot in our codebase (as you know) and we love being able to share references with a diesel transaction future, which is something only scoped futures allows (alongside this library, of course).

With the help of @guissalustiano we were testing to see if diesel-async scoped futures could be replaced by async closures in signatures. The reason we were curious was at first because it'd be cleaner for us in our codebase to rely on a rust syntax instead of explicit boxing or calling scoped future everywhere. We currently have more than a thousand of such query boxing!

So with this change main...guissalustiano:diesel_async:use_async_clousure we were really surprised to see some of these diesel transactions and queries were compiling cleanly, just replacing the |conn|Box::pin(async { ... }) with async |conn| { }.

So this discussion is in order to discuss, could the scoped futures library be replaced by the new syntax? Is there some lifetime edge case the new syntax does not cover? Am I misunderstanding something about the relationship between scoped futures and diesel async?

I'd love to understand better this situation and if it made sense to pursue such a change, which of course me and @guissalustiano would be more than willing to help with.

Thanks for the attention!

[weiznich]

At least the last time I tried the AsyncFn closure syntax in Rust was still too incomplete to be useful there as you couldn't express that the future returned by that closure must be Send. From a quick documentation check it seems like the relevant associated type is still unstable, so we cannot restrict it in stable code.

[lsunsi]

Got it, this makes perfect sense. Just for my understanding, can you point an use case that would be rendered impossible by this limitation? For example, would pipelining inside tokio be impossible for the lack of Send bounds?

The reason I ask this is because I'd expect a limitation like that to render my project useless, since we are fully tokio reliant with Send bounds everywhere. But incredibly, using async closures just work in some of code that I wouldn't expect to, so I see a gap in my understanding I'm trying to fill and hopefully propose something useful here!

[weiznich]

See here for a minimal example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b9aae9391797e6ba9a044ac20e6417da

The longer version is that this will cause issues as soon as you require that the future is send somewhere. I would have expected that the diesel-async test suite does not compile with such a change, but I did not double check that now due to capacity reasons.

[lsunsi]

Perfect, thanks a lot