So the instance itself, called this or self in OOP, can be NULL. But how can we get this info from gobject-introspection? My impression is that g_arg_info_may_be_null() does work only for the parameters of the instance, but not for instance itself?
So my current impression is that nullable property for instance parameters is not really supported by gobject-introspection. So we would have to allow NULL always for instance parameters in the bindings?
Well this is a difficult question, but I can not express the problem more clearly currently.
Some GMainContext API can take NULL (mostly for backward compatibility) as the instance parameter to indicate that the default context is the one being used. The wakeup() method requires a GMainContext instance because you’re always supposed to use it to wake up a specific GMainContext, not the default. It’s a low-level API for implementing main loops.
You can obtain the default GMainContext by using g_main_context_default(), which is what g_main_context_iteration() does internally when called with a NULL main context.
Alternatively, instead of using GMainContext, you can use GMainLoop and pass NULL for the GMainContext argument.
My question was not too much related to the GMainContext API but more to an available gobject-introspection function which gives us the information if the instance parameter can be NULL, like we have G_arg_info_may_be_null () for the other args. But such a function seems to be not available.
My current solution created this morning is that I allow generally passing NULL for the instance variable itself, and I forward NULL to the GTK functions. Before that I had not allowed passing NULL for the instance proxy object. That should work fine, the restriction is that the bindings can not detect if Null is passed for a case where GTK does not allow NULL, so for a wrongly NULL we will get a GTK crash now. Before we got a Nim exception. Both is a program termination, so both is OK.
It doesn’t look like a GIArgInfo is available for the instance parameter. If this is to be supported in GIRepository, I expect a function like g_callable_info_instance_may_be_null would be wanted, like we already have g_callable_info_get_instance_ownership_transfer because it may be difficult to include another ArgBlob for the instance parameter whilst maintaining binary compatibility of TYPELIB files. This is a downside to going via GIRepository and TYPELIB files rather than using the GIR files directly.
In this particular case, I think you’re fine with non-nullable instance parameters because g_main_context_default can be used to provide the default context. In fact, I think it’s clearer to explicitly reference the default context, e.g. GLib.MainContext.default().method().
As a general rule, no: instance parameters on a class type are not considered nullable.
Of course, there are exceptions—mostly limited to C API there were written 10 years before introspection was even a thing, and cannot be changed. Those exceptions are small, and you don’t strictly need to adhere to them; for instance, GMainContext API allows NULL but everyone should be using g_main_context_default() as the argument instead.
Another relevant thing is that we annotate the API for two reasons:
language bindings
documentation
The nullability of an argument is part of the documentation, and thus using (nullable) as its annotation generates a corresponding annotation in the API reference without necessarily having to write “the type of the argument, or NULL” manually each time.
As a general rule, no: instance parameters on a class type are not considered nullable.
OK, then I will go back to the initial behaviour, that is NULL is not allowed for instance parameters always. Maybe I will add an additional overloaded Nim function that accepts NULL for the Nim version of g_main_context_iteration() and g_main_context_wakeup().