You can always mark them as
skip if you don’t want bindings to use them, but that’s not the point here. Even from a C point of view,
gtk_button_new_with_label(NULL) are redundant. Technically you can pass
NULL in there but it doesn’t make much sense.
For the Rust bindings at least we use the constructors provided by C as “convenience” constructors for common patterns so users don’t have to first look at all the possible properties and figure out which they want to set and how. Want a button with a label? There’s a
gtk::Button::with_label() and you don’t have to worry about all the other possibilities yet, but if you wanted to you can completely side-step those convenience constructors and go via the equivalent of
The problem here is now that for languages that don’t care about nullability the above doesn’t really matter. Everything can be
NULL and that’s your problem if you do it wrong. But if the language expresses nullability then the above is mildly confusing. Why would you have to call
gtk::Button::with_label(Some("blabla")) if there’s already a
gtk::Button::with_label(None) the same or do they actually behave slightly different, etc.?
It’s not a big problem, it’s just yet another little papercut and we’ll manually fix that in the Rust bindings at least. Just sucks that every other bindings has to do the same work if GTK wants things to stay as they are currently.
I guess nullability is just something C developers don’t really spend much thought on as part of the API design as it’s all the same in C anyway