refactor: Remove async_trait in Catalog trait. #139
Description
After #140 get merged, we will be able to use async fn in trait, and async_trait macro is no longer needed.
Reacted by yi wang
async_trait in Catalog trait. #139After #140 get merged, we will be able to use async fn in trait, and async_trait macro is no longer needed.
Activity
hiirrxnn commentedon Jan 22, 2024
Could I work on this ? Please tell me what precisely is to be done here?
liurenjie1024 commentedon Jan 23, 2024
The release of rust 1.75 enables a fancy feature so that we no longer need to use
async_traitmacro, you can read this blog for reference.You can also see the
FileWritertrait in this pr as an example.jdockerty commentedon Jun 1, 2024
Is there any movement on this one? I see there was a prior PR to close, but it was closed pending upstream releases.
If there's nobody working on it anymore, I would like to take a shot at it if that's okay 👍
For mine/anyone else's reference, is there a preference to using
impl Future<Output = ...>or maintaining theasync fnsignatures withtrait_variantcrate?liurenjie1024 commentedon Jun 2, 2024
Hi, @jdockerty Thanks for you interest, I think we can go on this work after rust-lang/impl-trait-utils#27 is release on new rust release.
Xuanwo commentedon Jun 10, 2024
I personally do not favor adopting
async in traitfor theCatalogAPI because it compromises object safety. Users will no longer be able to useBox<dyn Catalog>. All APIs related toCatalogshould include generic parameters.Xuanwo commentedon Jul 5, 2024
I propose closing this issue as it's unlikely we'll remove
async_traitfromCataloguntil easier methods for implementing object-safe trait objects are available. Additionally, catalog API calls are usually not on the critical path in most of our use cases. Adding such a maintenance burden isn't worth it.cc @liurenjie1024 @jdockerty
liurenjie1024 commentedon Jul 6, 2024
+1, we can close this first.