apache
refactor: Remove `async_trait` in `Catalog` trait.
After #140 get merged, we will be able to use async fn in trait, and async_trait macro is no longer needed.
Could I work on this ? Please tell me what precisely is to be done here?
The release of rust 1.75 enables a fancy feature so that we no longer need to use async_trait macro, you can read this blog for reference.
You can also see the FileWriter trait in this pr as an example.
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 :+1:
For mine/anyone else's reference, is there a preference to using impl Future<Output = ...> or maintaining the async fn signatures with trait_variant crate?
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?
Hi, @jdockerty Thanks for you interest, I think we can go on this work after https://github.com/rust-lang/impl-trait-utils/pull/27 is release on new rust release.
I personally do not favor adopting async in trait for the Catalog API because it compromises object safety. Users will no longer be able to use Box<dyn Catalog>. All APIs related to Catalog should include generic parameters.
I propose closing this issue as it's unlikely we'll remove async_trait from Catalog until 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