Skip to content
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

Suggestion: SyncFnOnce #11

Open
yokomizor opened this issue Nov 9, 2023 · 3 comments
Open

Suggestion: SyncFnOnce #11

yokomizor opened this issue Nov 9, 2023 · 3 comments

Comments

@yokomizor
Copy link

yokomizor commented Nov 9, 2023

Hi,

I am no sure if something like a SyncFnOnce wrapper exists and if it would even be possible to implement.
If possible, it would be nice since FnOnce only operation is call_once, which consumes self.

@yokomizor yokomizor changed the title suggestion: SyncFnOnce: would it be possible to implement something like this? Suggestion: SyncFnOnce Nov 9, 2023
@yokomizor yokomizor reopened this Nov 9, 2023
@rkuhn
Copy link
Member

rkuhn commented Nov 10, 2023

Sounds doable at first sight, but it makes me wonder: under which circumstances would you need this? Sync is about sending references around, and sending a reference to FnOnce isn’t useful (as you point out).

@yokomizor
Copy link
Author

I stumbled upon this when I had a type that for other reasons had to be Sync while holding an Option<Box<dyn FnOnce() -> SyncFuture<BoxFuture<'static, SomeType>>>>. I ended up implementing the wrapper myself, but it feels like a good use case for sync_wrapper.

@rkuhn
Copy link
Member

rkuhn commented Nov 15, 2023

Sorry for the delay, other things kept me from properly thinking this through. The reasoning seems sound to me: SyncWrapper works because it only permits operations on exclusive references, so SyncFnOnce should work, too, because the only thing you can do with it requires you to (exclusively) own the value.

Would you like to try your hand at an implementation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants