Heya, I came across the following compilation error:
Scenario
#[async_trait]
pub trait Trait {
async fn cfg_param(&self, param: &u8);
// ---------------------------- lifetimes in impl do not match this method in trait
}
struct Struct;
#[async_trait]
impl Trait for Struct {
async fn cfg_param(&self, #[cfg(any())] param: &u8, #[cfg(all())] _unused: &u8) {}
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetimes do not match method in trait
}
This is similar to #226, but in this case the parameters have lifetimes.
It's not possible to have attributes in type parameter position, so we can't just copy the #[cfg] attributes per lifetime.
Dynamically working out which parameters are part of the same lifetime group is not necessarily easy (e.g. if someone has multiple #[cfg(..)] combinations which don't have the same #[cfg(feature_a)], #[cfg(not(feature_a))] pattern).
Adding a custom #[async_trait(same_lifetime_group)] attribute per parameter detracts from the usability.
Generating a different combination of the impl per combination of #[cfg] is possible, but is it worth the complexity?
Not supported by async-trait, but users can create a separate function with the same signature, and in the trait impl they call the separate function.
Do you think async-trait should support this case? It may not be worth supporting, since option 4 is hard to get right, and may be hard to maintain in the long run / have good diagnostics for.
Heya, I came across the following compilation error:
Scenario
This is similar to #226, but in this case the parameters have lifetimes.
The expanded code shows what's happening:
Options
(that I can think of)
#[cfg]
attributes per lifetime.#[cfg(..)]
combinations which don't have the same#[cfg(feature_a)]
,#[cfg(not(feature_a))]
pattern).#[async_trait(same_lifetime_group)]
attribute per parameter detracts from the usability.impl
per combination of#[cfg]
is possible, but is it worth the complexity?async-trait
, but users can create a separate function with the same signature, and in the trait impl they call the separate function.The last option is:
Do you think
async-trait
should support this case? It may not be worth supporting, since option 4 is hard to get right, and may be hard to maintain in the long run / have good diagnostics for.