-
Notifications
You must be signed in to change notification settings - Fork 291
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
Shared context #461
Shared context #461
Conversation
4f53ef6
to
085d615
Compare
What I had in mind was actually much simpler. When there is only one callback, the caller can easily borrow the context exclusively in the closure environment. We would only need to change the |
It's certainly possible, I opted not to to maintain a more coherent API (and was considering commenting on it). Consider how the caller would otherwise need to build multiple kinds of adapters (like these or these) when interacting with it. From your comment I gather that might not be an overriding concern for you? |
It would be nice if the functions were documented (preferably with examples). After all, it is impossible to understand what We have to study the implementation. |
I would prefer keeping the API simple and only add the context variant for |
Ok, which of the three variants above do you want |
I would say the first variant (keep the API the same, just add a context), except that all |
☔ The latest upstream changes (presumably #468) made this pull request unmergeable. Please resolve the merge conflicts. |
Closing now since things are moving and I don't have the time to do this. |
Supersedes #459
Based on this comment it seems like there's interest in passing shared contexts around in the raw API, this PR extracts just that aspect from #459 in so that at least the context aspect of #456 will be accepted.
Motivation: Passing a context around is necessary to allow
eq
andhasher
to share the same mutable environment, Both can't implementFnMut
and capture the same environment, because those two captures would both need to have exclusive access to it which is disallowed by Rust's aliasing rules.There's three levels of possibly increasing controversy in this PR, separated by three commits:
*_with_context
methods, maintaining the same API in the process (eq
isimpl FnMut
).impl Fn
for the new methods, meaning if you want to use a mutable shared environment there you must use the&mut C
context variable to pass it around.&mut C
.If there is interest in passing a context around like this, feel free to decide which one you want to keep, and which one to discard.
Thank you!