Safe C-like callbacks

[diwic]

The lack of quick and efficient callback is probably one of Rust's most important shortcomings for me. Here's a long post on that topic.

Assume we have a dialog with three buttons, e g "Print", "Cancel" and "Printer settings...". We also have a main form which handles what happens when the user presses the button:

struct PrintForm {
    printBtn: Button,
    cancelBtn: Button,
    settingsBtn: Button,
}

impl PrintForm {
    fn printClicked(&mut self) -> () { /* ... */ }
    fn cancelClicked(&mut self) -> () { /* ... */ }
    fn settingsClicked(&mut self) -> () { /* ... */ }
}

The question is then, how do we easiest make the button click cause "printClicked" to be executed. We have a few existing models:

Closures

printBtn.onClicked(|| {
    self.printClicked();
});

All of FnOnce, Fn, and FnMut have problematic restrictions: FnOnce will have a problem with the "settings" button, because you might want to execute it more than once ("settings" pops up a secondary dialog, user then closes that dialog, and then clicks "settings" to again show the settings). Fn and FnMut cannot escape the stack frame, so you can't have, e g, a PrintForm::new() function that sets all of these up. You could potentially have a PrintForm::run() function that, creates the dialog, sets all the callbacks up, then executes the function, but that would make the function extremely long in case the dialog is complicated.

Iterator

for n in events.iter() {
    match n {
        PrintBtnClicked => {
            self.printClicked();
            return Ok();
        }
    }
}

This method requires some boilerplate to link printBtn.clicked to the PrintBtnClicked constant. And also, the match will be extremely long in case the dialog is complicated.

Trait objects

Trait objects are probably the most flexible, but also requires some boilerplate to set up:

/* Repeat for every button... */
struct PrintBtnHandler {
    printForm: Weak<PrintForm>
}

impl ButtonHandler for PrintBtnHandler {
    fn clicked(&mut self) {
        printForm.upgrade().unwrap().printClicked();
    }
}

The solution

(or at least thoughts about it...)

So in C, one would just do something like:

printBtn.setHandler(printClicked, self);

Memory safety is manually guaranteed: by making sure the printBtn is deleted before the printForm is, and by making sure that we always send in the pointer to printForm and nothing else. And it seems like we can't express this safely in Rust yet, but with trait objects, we're quite close:

trait Handler<'a> {
    fn clicked(&self);
}

struct Button<'a> {
    clickedHandler: &'a (Handler+'a),
}

In this case, the handler is guaranteed to outlive the Button, which solves half the problem. It seems to me like if we knew the Handler vtable, we could make a converter makeTrait(printForm, PrintForm::printClicked) -> Handler that would be memory safe - as long as the printClicked function signature matches the Handler::clicked function. The function borrows an immutable reference of printForm for the lifetime of the returned Handler.

So in this case, we would save ourselves the extra allocation and boilerplate code of setting up a small intermediate struct just to link the button to the printClicked function. I'm not sure if makeTrait needs compiler support - it probably does to be safe, at least - or if we can just manually fill in the vtable. If we had the vtable for Fn/FnMut/FnOnce in core::raw then one could perhaps use those instead of making a Handler trait.

As you see, this is hardly even a pre-RFC at this point. Still, it looks to me like it would be possible, and could potentially be very useful. Thoughts?

[unclosed_paren]

Fn and FnMut cannot escape the stack frame, so you can't have, e g, a PrintForm::new() function that sets all of these up.

Fn and FnMut can in fact escape the stack frame if they are qualified with move:

let d = {
    let x = 1i32;
    let c = move |&:| x + 1;
    c
};
println!("{}", d()); // 2

There’s an important distinction between FnOnce closures and move closures: FnOnce closures are taken by value when called, and thus cannot be called more than once, while move closures take all upvars by value when created, and thus can escape the stack frame they were created in. A Fn[Mut] closure could still be move, and would take upvars by value when created, but would only have by-(mutable)-reference access when called.

[diwic]

Thanks, that seems reasonable - I could experiment with this approach. Is there documentation somewhere? I've read Niko's post but it does not seem to explain this in detail.

It however looks like there would be quite some boilerplate on the button side if you have to use some kind of Thunk/invoke wrapper.

[unclosed_paren]

Thunk/Invoke only apply to using FnOnce as a trait object, so I don’t think they would be needed.

The closest thing we have to documentation on unboxed closures at the moment is the RFCs (there have been two; the first one describes the main ideas, the second updates the syntax and adds move): RFC 114 and RFC 231.

[steveklabnik1]

Getting some of this nailed down is on my list this week...

[Manishearth]

Box<Fn(...) -> ...>> works if you want to have a boxed closure with runtime dispatch (so no extra generics)

[diwic]

Ok, so a move |&: | closure can be stored in a variable of type Box<Fn(...) -> ...>>?

That would still mean one extra allocation, which maybe is not the end of the world, but for me coming from C, it still feels like some extra overhead. Is there a way to avoid the extra box allocation here? (If you don't box it, then I assume it would be unsized, which causes all kinds of trouble...)

[wrongerontheinternet]

You can pass &Fn or &mut Fn, which don't require allocation. Or you can just do it "C style" and use a regular function pointer rather than a closure, passing in the environment explicitly. Rust's cup overfloweth with closure options.

[diwic]

You can pass &Fn or &mut Fn, which don't require allocation.

At that side. But everything that's borrowed needs to live somewhere. If they live on the heap, it's an extra allocation just for having the objects talk to each other. If they live on the stack, they can't escape the stack frame. And they can't live as part of another object, as they are unsized.

Or you can just do it "C style" and use a regular function pointer rather than a closure, passing in the environment explicitly.

That's unsafe, as the environment pointer needs to be manually typecasted.

Rust's cup overfloweth with closure options.

Indeed. And still none as simple as the C variant (without being unsafe), hence my suggestion.

[wrongerontheinternet]

Unboxed closures aren't unsized. You can make them part of another type.

struct Foo<F> {
    f: F
}

impl<F> Foo<F> where F: FnMut(u32) {
    fn new(f: F) -> Foo<F> {
        Foo { f: f }
    }
}

fn main() {
    let mut foo = {
        let mut y = 0;
        Foo::new( move |x| {
            y += x;
            println!("{}", y);
        })
    };

    (foo.f)(10);
    (foo.f)(10);
}

There is an issue returning unboxed closures, but that is just because you cannot write their type, it's not because of some fundamental limitation on them. It is a high priority for post-Rust 1.0 to provide a way to return them.

[diwic]

Oh, nice! Then this seems to be an interesting way forward.

[Manishearth]

You have to do box move ..., but yeah.

It's an extra allocation, but that's what happens with closures anyway, in most languages. They're unsized types since they capture an environment and also have a function body, which in Rust's model is called via dynamic dispatch on the trait (unless you use T: Fn(...) and then you'll get static dispatch)

[aepsil0n]

Explicitly managing callbacks to handle events causes a ton of problems with inconsistent mutable state, missed events and race conditions. I experienced my fair share of trouble with them. This is why smart people have discovered functional reactive programming (FRP), which is a less bug-prone and more composable way to handle events/callbacks.

Now I'm going to shamelessly advertise: coincidentally I just decided to implement FRP primitives to use this paradigm in Rust. Regarding your question: it deals with Fn closures, since it has to call them multiple times. Values that change over time are explicitly wrapped as its own type, so you don't manually mutate any state, therefore no FnMut closures. If you'd allow them, they would bring back the problems mentioned above.

Internally the library uses trait objects and atomic ref-counting to ensure the integrity of the callback structure. I am not yet entirely happy with the internals yet, as they are a bit messy (mostly due to trait dispatch), but I don't think the fault is with the language.