Make async RegisterOperation functions take self by value - #258
Make async RegisterOperation functions take self by value#258peterkrull wants to merge 3 commits into
Conversation
|
Hey there! Thanks for the contribution. I'm in two minds about it. If we do this somewhere, we should do it everywhere. Principle of least surprise. So what are the ramifications?
So... I don't really know what's best. W.r.t. the size optimization, I hope (and am trying) to make the compiler just do the right thing so people don't have to do that optimization by hand anymore. So in a while the optimization shouldn't be necessary anymore. I'll take some time to think about it |
|
I also think it should be consistent between sync and async, I just wanted to hear you out first. The question is whether there are any legitimate patterns which are not possible when the You know best what the potential timelines are for you landing device-driver 2.0, and your work with the compiler (which I am also looking forward to!) So whether these changes make sense in terms of the compiler making it redundant in the near term is your call. |
|
The only regression in the generated code will be that the address computation will be performed multiple times, whereas previously users had the opportunity to store this value. (which 99% of the users will not do) I think this benefit is inconsequential, especially in the light that a HAL will perform the same kind of address computation possibly dozens of times when interacting with the interface for the same device-driver register operation. Code-size-wise this change does not change anything, and opens the possibility of async future erasure as demonstrated. I say this is a meaningful improvement overall. |
|
Ok, then I'm inclined to merge, but I do think it should take ownership across the board then. @peterkrull can you do that? If not I'll pick it up when I get to it |
|
Sync |
Hey,
I have started playing around with this library, and inspired by your blog post I wanted to make my own driver do most async operations using the pass-through pattern you suggest. However that is currently not easy to do with this library, since
RegisterOperation::{read, write, modify, etc..}_asynctake&mut selfrather than justself. So the returned future would borrow theRegisterOperationthat is constructed locally in this function.The result is that I am unable to do this:
but rather have to resort to async+awaiting:
This PR just change those
x_asyncfunctions to takeselfrather than&mut selfand all tests still seem to pass, and the first snippet above compiles. Of course this means one cannot construct aRegisterOperationonce and re-use it multiple times, but I am also not sure if there is any benefit to that over just constructing it again. I have not touched the sync functions here, but perhaps they should also takeselfjust for symmetry?