How to pass channel into Closure?

[dakom]

Picking up from #1126

Consider the following:

use futures::{Future, Async, Poll};
use futures::sync::oneshot::{Sender, Receiver, channel};
use futures::task::current;
use wasm_bindgen::prelude::*;
use wasm_bindgen::JsCast;
use web_sys::*;

struct AsyncCounter {
    value: f64,
    target: f64,
    state: CounterState,
}

enum CounterState {
    Init,
    Counting { err_receiver: Receiver<JsValue> },
    Error (JsValue)
}
impl Future for AsyncCounter {
    type Item = JsValue;
    type Error = JsValue;

    fn poll(&mut self) -> Poll<Self::Item, Self::Error> {
        match &self.state {
            CounterState::Init => {
                //Setup callback for updates
                let (err_sender, err_receiver):(Sender<JsValue>, Receiver<JsValue>) = channel();
                let task = current();

                let closure = Closure::wrap(Box::new(move || {
                    //This is not allowed
                    err_sender.send(JsValue::from_str("foo"));
                    task.notify();
                }) as Box<FnMut()>);

                // TODO: handle cancellation with clearTimeout
                window().unwrap().set_timeout_with_callback_and_timeout_and_arguments_0(closure.as_ref().unchecked_ref(), 1000).unwrap();

                //Move to counting state
                self.state = CounterState::Counting {err_receiver} ;
                let task = current();
                task.notify();
                Ok(Async::NotReady)
            },
            CounterState::Counting {err_receiver}  => {
                if self.value == self.target {
                    Ok(Async::Ready(JsValue::from_f64(self.value as f64)))

                } else {
                    self.value += 1.0;
                    Ok(Async::NotReady)
                }
            },
            CounterState::Error (err) => {
                Err(err.clone())
            }
        }
    }
}

If I remove that line: err_sender.send(JsValue::from_str("foo")); then it compiles fine. But with that line, I can't seem to get around the trait constraints.

Any tips?

(I've left out the receiver polling just to keep the example a bit more concise - but we can imagine that polling it could move the state to CounterState::Error)

[chpio]

could it be because of:

• the closure being a FnMut, not FnOnce
• and the sender consuming it self in the send method

?

[alexcrichton]

Sounds like @chpio has already solve this! With Closure you can't use FnOnce (yet) so you'll want to wrap the err_sender in an Option which you can take().unwrap() to assert the closure is only called once

[dakom]

Thanks y'all! Looking forward to trying it out soon...

you'll want to wrap the err_sender in an Option which you can take().unwrap() to assert the closure is only called once

Is this a common Rustism?

[Pauan]

Is this a common Rustism?

Yes. Or at least, I've used it a fair amount.

[chpio]

Is this a common Rustism?

i think it is, replace (take is just a sugar-y wrapper around replace) is used a lot in rust.

[dakom]

The idea of something consuming self makes my head explode...

I'm still not totally following why doing that causes the Closure to try to be only FnOnce ...

I mean, I get it from like a casual perspective - can't blink something out of existence twice... but I don't really get it?

[Pauan]

@dakom It's just the natural consequence of Rust's memory management (i.e. no garbage collector).

When the Rust compiler sees a closure, like this...

move || {
    do_something(foo);
}

There are three possibilities: the closure can be Fn, FnMut, or FnOnce.

The Rust compiler tries to make the closure as useful as possible. Since Fn can be used anywhere, Rust first tries to make the closure Fn.

However, if the closure captures mutable references then that doesn't work. So then Rust tries to make the closure FnMut, which works with mutable references.

But if the closure captures a variable and then tries to move it, it cannot be Fn or FnMut. So in that case the Rust compiler makes the closure FnOnce, which is the most restrictive.

Why can't the closure be Fn or FnMut? Consider this closure:

let x = vec![];

let f = move || {
    drop(x);
};

Here we are moving the variable x into the closure f. The closure tries to move the variable x (because it calls the drop function, which consumes its argument by value).

The Rust compiler rightfully says that the type of f is FnOnce(). What would happen if the Rust compiler used Fn() or FnMut() instead? Well, in that case we could drop x twice!

f();  // Drops x
f();  // Drops x again!

Oops, now we have a double-free, and therefore undefined behavior. Double dropping isn't the only bad thing that can happen, use-after-free could happen as well!

This happens because Fn and FnMut can be called multiple times. To prevent that, Rust restricts the closure to be FnOnce, which means it can only be called one time.

How does the Rust compiler enforce that an FnOnce closure is only called once? As an example, let's look at the definition of Option::map:

pub fn map<U, F>(self, f: F) -> Option<U> where F: FnOnce(T) -> U {
    match self {
        Some(x) => Some(f(x)),
        None => None,
    }
}

Notice that the type signature says that it accepts an FnOnce(T) -> U closure.

What that means is that the map function promises it will only call the closure one time, and this is enforced within the body of the function. So if map tries to call f multiple times then it will get a compile error.

What if you changed the map function to use FnMut or Fn instead? In that case it would still work if you called map with an Fn or FnMut closure, however if you tried to call map with an FnOnce closure then it will error.

The way to think of this is that there are two sides: the side which creates the closure, and the side which calls the closure.

For creation, it is most useful to create Fn closures, since they can be called as Fn, FnMut, or FnOnce. It is most restrictive to create FnOnce closures, since they can only be called as FnOnce.

For calling, it is most useful to accept FnOnce closures, since any closure can be FnOnce. And it is most restrictive to accept Fn closures, since then the closure cannot capture mutable references, and it cannot move captured variables.

Another way to think about it is that the caller decides what capabilities the closure has: if a caller (like map) accepts an Fn, then that means the closure can only be Fn.

On the other hand, if the caller accepts FnMut, then that means the closure can be Fn or FnMut. And if the caller accepts FnOnce then that means the closure can be Fn, FnMut, or FnOnce.

Right now wasm-bindgen only accepts FnMut closures, which means you can use Fn or FnMut closures with wasm-bindgen, but you cannot use FnOnce closures.

Using Some(value) and then using .take().unwrap() is one way to "convert" an FnOnce closure into an FnMut closure:

let mut x = Some(vec![]);

let f = move || {
    let y = x.take().unwrap();
    drop(y);
};

Notice that the closure is no longer trying to move x, instead it is moving y. That's okay, because y isn't a captured variable, it's a local variable.

Since the closure doesn't move captured variables, it is no longer FnOnce, instead it is now FnMut.

That means you will get a runtime panic if the closure is called multiple times, but that's better than undefined behavior!

You can read more about the nitty gritty of Rust closures here:

https://krishnasannasi.github.io/rust/syntactic/sugar/2019/01/17/Closures-Magic-Functions.html
http://huonw.github.io/blog/2015/05/finding-closure-in-rust/
https://stevedonovan.github.io/rustifications/2018/08/18/rust-closures-are-hard.html
http://gradebot.org/doc/ipur/closure.html

[dakom]

wow, GOLD.... thanks again!!!!

Gotta print up all these issue posts into a standalone book of its own...

let f = move || {
    let y = x.take().unwrap();
    drop(y);
};

x isn't moved there?

(btw small typo - I think you forgot the F: on where FnOnce(T) -> U )

[Pauan]

P.S. With the final example, you might be wondering why it no longer tries to move x.

The reason is actually really simple: the Option::take method accepts &mut self, not self, and therefore it does not consume its argument, instead it accepts a mutable reference to its argument.

Because x.take() does not consume x, and since nothing else touches x, we can conclude that x is not moved.

On the other hand, the Sender::send method does accept self, and therefore it consumes it. That's why calling err_sender.send(...) causes err_sender to be moved.

This is the sort of reasoning that the Rust compiler uses to determine whether a variable is moved or not. It's all based purely on the types.

[Pauan]

(btw small typo - I think you forgot the F: on where FnOnce(T) -> U )

You're right, I've fixed it, thanks!

[dakom]

ahhh... and I vaguely remember getting stuck before on that exact same point about not-moving x because it doesn't need to, e.g. the move keyword being more like a hint rather than an explicit instruction.

really appreciate it, feels like Rust is a big enough language that it's really hard to remember all this when only dabbling spare-time. kinda kicking myself for re-asking some of the same questions, but that's life I guess!

it'll click eventually though, hopefully... thanks again!

[chpio]

let f = move || {
    let y = x.take().unwrap();
    drop(y);
};

x isn't moved there?

yes, it's moved into the closure, but you call the closure (in case of a FnMut) by &mut, so it can only give you &mut access to the captured values (that's because it can be called multiple times).

[dakom]

okay, thanks @chpio - I think I'm getting a little confused by "move" here... since although it's moved, because it can be called multiple times it's not dropped until the closure itself is dropped... or something like that..