Re: nullability

[Mikhail Zabaluev <mikhail zabaluev gmail com>]

Hi,

Piping in to add to the thread on nullability of return values, which
I sadly missed due to not being subscribed until now.

Indeed, as has been mentioned, changing the default to (nullable) will
massively inconvenience some strongly typed bindings. With Rust, my
approach has been to bind non-nullable outputs to value types that
have undefined behavior if the underlying pointer is null, but add an
assertion to check the pointer and panic if it's found to be null. My
reasoning is that such condition mostly occurs in two scenarios:

- A legitimately nullable return value has not been annotated as such.
This is arguably an annotation bug and it can be easily fixed
(breaking some bindings, but for a good reason).
- There has been a failed g_return_val_if_fail() that most likely
indicates a critical programming error. This makes fair grounds for a
thread panic.

The assertion check can be tuned to only be compiled into debug builds.

And as has been implemented for untyped and unannotated pointers, it's
not a big deal for the return value to be nullable, as bindings may
map it to their language's representation of an untyped "raw" pointer,
or skip the function altogether. Nullable callback pointers are fine
as well.

Hope this helps,
  Mikhail