-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Phase out async_trait macro #2684
Comments
This is indeed the plan! The new interfaces for #1070 make use of |
The Rocket/core/lib/src/listener/listener.rs Lines 8 to 19 in fd29404
I would love help in moving Rocket away from pub trait FromData<'r>: Sized;
pub trait IoHandler: Send;
pub trait Handler: Cloneable + Send + Sync + 'static;
pub trait FromFormField<'v>: Send + Sized;
pub trait Fairing: Send + Sync + Any + 'static;
pub trait FromRequest<'r>: Sized;
pub trait FromForm<'r>: Send + Sized; The process would be to:
Repeat this process once per trait. A commit per removal would be fantastic, finalizing the PR with a commit that removes the That's it! Any help would be appreciated. Edit: we cannot make this change to traits that are object safe since doing so would make the trait not object safe. The following traits must be object safe, and thus (for the time being) must continue to use
Edit 2: it is possible that we can't migrate any of these traits due to rust-lang/rust#100013. I've run into an issue attempting to migrate |
What's missing?
Rocket currently re-exports the
async_trait
crate for use with itsFairing
(and possibly others). As of rust 1.75.0 this is no longer needed, therefore it would be nice to get rid of this dependency and use actual async functions for these traits.This generally improves compile times, dependency count and IDE responsiveness.
Ideal Solution
For v0.6, remove async_trait (or put its usage behind a feature) and use async functions directly. This would raise the MSRV to 1.75.0.
Why can't this be implemented outside of Rocket?
This is an integral part of Rocket.
Are there workarounds usable today?
No. You bypass the need for the macro attribute by returning a
Box<dyn Future<Output = T> + Send + 'a>
, but this is unwieldy.Alternative Solutions
No response
Additional Context
No response
System Checks
The text was updated successfully, but these errors were encountered: