nullablity

[Colin Walters <walters verbum org>]

One thing I had to refresh my memory on is all of the long conversations on nullable.  There's a section on 
nullability on the wiki:
https://wiki.gnome.org/action/show/Projects/GObjectIntrospection/Annotations
But it doesn't really capture the important subtleties here.

In this bug, Christoph Reiter made an important comment:

https://bugzilla.gnome.org/show_bug.cgi?id=660879#c41

Basically he was suggesting that we treat input pointer types as (not nullable) by default, but
return values as (nullable).  The first part had mostly been happening
slowly as people added (allow-none), which is now (nullable). 

But while I have seen some annotations for return values as (allow-none),
in practice there are a lot of APIs out there that are not annotated
with this.  To pick one example, `g_dbus_connection_get_peer_credentials`.

For dynamic language bindings and static languages which are nullable-by-default
(e.g. Java), this is an OK situation.

Vala AFAIK is in the middle here as it has a concept of nullabilty but it's
"just" a compiler warning.

But for languages which have a hard distinction (e.g. Haskell, Rust), this situation
is going to be problematic.

The major question to me now is - do we change g-i to assume return
values are nullable by default?  And have a review pass where we add
a lot of (not nullable)?

Or do we say return values are (not nullable) and require (nullable)
for ones that are?  

The current state seems to be from Ryan's patches that we ended up
treating parameters and return values the same - assuming not-nullable,
but in reality that leaves APIs like `g_dbus_connection_get_peer_credentials`
as possibly returning NULL.

And a pass where we change things like that now would be an API
break for "nonull" languages.

Thoughts?