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

more elegant way to conditionally pop #85

Open
Be-ing opened this issue Apr 14, 2022 · 2 comments
Open

more elegant way to conditionally pop #85

Be-ing opened this issue Apr 14, 2022 · 2 comments

Comments

@Be-ing
Copy link

Be-ing commented Apr 14, 2022

I have code like this in two places in my application now:

        while let Ok(AudioEngineToGUIMessage::BufferSizeChanged(_)) = from_audio_rx.peek() {
            if let Ok(AudioEngineToGUIMessage::BufferSizeChanged(frames)) = from_audio_rx.pop() {
                let mut buffer_size_frames = buffer_size_frames.borrow_mut();
                *buffer_size_frames = frames;
            } else {
                unreachable!("AudioEngineToGUIMessage not a BufferSizeChanged message?!")
            }
        }

The while let immediately followed by if let feels verbose and hacky... is there a better way to do this?

@mgeier
Copy link
Owner

mgeier commented Apr 15, 2022

I guess frames is just a number, right? Something that's cheap to copy?
In this case you can probably extract it directly from the peek() call.

Maybe something like this (untested!):

        while let Ok(AudioEngineToGUIMessage::BufferSizeChanged(frames)) = from_audio_rx.peek() {
            let _ = from_audio_rx.pop();
            let mut buffer_size_frames = buffer_size_frames.borrow_mut();
            *buffer_size_frames = frames;
        }

But for move-only types I wouldn't know a better solution.

We could try to add a "conditional pop" function to the API?
Something where you can pass a closure which can decide if the element should be popped or not?
But still we could only pass a reference to the closure, we would still not get ownership.
Or there could be two closures, one for checking and one for getting ownership on success? But this seems a bit convoluted, doesn't it?

@mgeier
Copy link
Owner

mgeier commented Sep 13, 2022

@Be-ing Did you have a chance to try my suggestion? Does it work for you? Or is there anything else to do?

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