Boxed Fns / F: Fn type parameters?

[dhardy]

Widgets like CheckBox, TextButton take an optional closure, called on activation/toggle. Options to store this:

<F: FnMut(&mut EventMgr, bool)>
...
on_toggle: Option<F>,

Using a type parameter is the "rustic" option. Problem: the parametrized widget's type is not nameable. With RFC#2524 or RFC#2515 this may be less of an issue, at least for types only used locally. A compound widget such as a pre-built dialog might contain several type parameters, and having to include these as part of the type could be a pain. (This is event a problem if the closure's type is fixed in the compound widget, since we can't name the type of functions.)

For the same reason, we don't want a lifetime parameter, which implies that all captured variables must be moved.

on_toggle: Option<Box<dyn FnMut(&mut EventMgr, bool)>>,

Problem: doesn't support Clone, which is sometimes useful.

on_toggle: Option<Rc<dyn Fn(&mut EventMgr, bool)>>,

Use Rc and Fn (not FnMut). Okay, but now we don't support mutable captured variables. (Alternative: use Rc<RefCell<dyn FnMut ..>>. Viable, but not sufficiently useful for the extra functionality?)

on_toggle: Option<fn(&mut EventMgr, bool)>,

Use of only a function pointer is simpler, automatically supports Clone, and since we already had Fn(..) + 'static, the only functionality we lose is capturing of moved, constant variables. So is this the better option?

[dhardy]

Note: having widgets support Clone was considered important, but barely seems to have any use in practice (in the few cases where multiple instances of the same widget are desired, a constructor method works fine).

On the other hand, these action handlers are normally only used to send a message to the real handler from the context of some parent widget, which it turns out is a neat event-handling pattern — in other words, I see no good rationale for why we'd want to support FnMut.