With gtkmm if I create a subclass of gtk::Application then I just provide methods oncommandline, on_activate, etc. and they are the event handlers, no need for explicit connection: the data model is supporting making things easy, albeit implicit by convention.

Rust has no notion of inheritance and so gtk-rs just exposes the functions to connect handlers to events. This fits well with the computational model since there is the _ parameter in closures to say "I don't care, just do the type inference thing so it all fits together".

D is like C++ and could use convention over configuration and yet actually does things as Rust does, providing the configuration tools. So currently GtkD does not provide a class/inheritance based binding to Gtk as C++ does even though it has classes and inheritance as C++ does. But in doing things like Rust, D ends up being very verbose because everything has to be declared correctly.

I am not sure this is actually a big issue, it just seems a little "missing a thing"?

Is this making any sense?