-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Make storage futures only borrow client, not self, for better ergonomics #561
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -300,21 +315,32 @@ fn generate_storage_entry_fns( | |||
|
|||
let client_fns = quote! { | |||
#docs_token | |||
pub async fn #fn_name( | |||
pub fn #fn_name( | |||
&self, | |||
#( #key_args, )* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self; key args have a lifetime of 'a, which is the same as the lifetime of the client struct.
Should key args have a lifetime of 'b, and the returned future rely on both 'a and 'b, to avoid any unnecessary restrictions on how the future is used in conjunction with these references?
It would be good to test and see whether a single bound is overly restrictive (as well as to test that we can create and later use futures so that we confirm it's all good in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a little testing and it seems OK to use the 'a
lifetime for key_args and client; from reading around I think Rust will pick the correct smallest lifetime that all params with 'a
use anyway, so no need to add other lifetimes.
Capitalise comment Co-authored-by: Tarik Gul <47201679+TarikGul@users.noreply.github.com>
Capitalise comment Co-authored-by: Tarik Gul <47201679+TarikGul@users.noreply.github.com>
Just a small qol improvement that allows one to get a future back from a storage query and await it later without needing to store any intermediate variables due to unnecessarily large lifetimes being captured by said futures.
Without this you'd need to write:
But with it you can chain all the way up to the future like so:
Closes #558