13 ms·
I don't use Rust but was curious if this was a real or imagined problem--it seems to be the latter. Two points: 1. the example could have made a pure callback
by karmakaze 5y ago
I don't use Rust but was curious if this was a real or imagined problem--it seems to be the latter. Two points:
1. the example could have made a pure callback function that takes a mut& db param and pass thaf param to the 'do'er function. Why is this not required anyway? i.e. How does Rust know/decide who owns the mut& db if both the closure and the function that creates the closure can reference it?
2. as mentioned, the complaints about async seems to apply to closures in general even if used synchronously, AFAICT.
Best to think of this post as quirks when working with closures in Rust. It would have been far better to list each with workarounds.
- brabel 5y ago> the example could have made a pure callback function that takes a mut& db param and pass thaf param to the 'do'er function. No. If you did that, you could only pass functions in that took the db as a closure argument, nothing else... you're thinking about this example only, and forgetting the problem is with the general case of capturing whatever is needed for the callback to work.
- karmakaze 5y agoOk, so then the problem statement is how to do dependency injection of lifecycle references into closures. This is specific and asking quite a lot of a single entrypoint function. The closure 'at some point' (either at the end, or coordinated give then get calls) would have to transfer ownership. At this point you'd likely be better off making an interface and not a single entry/exit closure.