-
-
Notifications
You must be signed in to change notification settings - Fork 84
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
Methods created are fn (&Struct) -> ...
, rather than for<'_> fn (&Struct) -> ...
#133
Comments
Looking at how the macro expands, it seems the fn g1<'life0>(&'life0 self);
fn g2<'life0, 'async_trait>(&'life0 self)
where 'life0: 'async_trait; I guess Rust introduces this |
In particular, it seems it's the Edit: This may be a limitation of the compiler. |
I guess the reason this works without
So with the I guess the "correct" solution would be for |
It seems this is just an inconsistency in how Rustc prints the types. There was a real issue I was having, but as far as I can tell it's ultimately due to limits in Rustc. |
I don't understand the sorcery of HRTBs and async well enough to know if there's a major difficulty with this, but it seems to be relevant when trying to accept the function as an argument.
Consider this:
This tells us
Struct::f
has typefor<'_> fn(&Struct) -> impl Future {Struct::f}
.Struct::h
has typefor<'r> fn(&'r Struct) {<Struct as Trait>::h}
.But
Struct::g
isfn(&Struct) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::g::<'_, '_>}
.If this can't be changed to have a
for<'_>
bound, I guess that should be documented as one of the crate's limitations...The text was updated successfully, but these errors were encountered: