Re: nullablity

[Iñaki García Etxebarria <garetxe gmail com>]

Hi,

On Mon, 2015-10-05 at 15:49 -0400, Colin Walters wrote:
> 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?
I have no thoughts about which of the two ways you suggest for fixing
the return nullability info is best, but for the Haskell GI bindings
the API break is perfectly fine, and desirable in this case: the
current generated API is simply incorrect when the return value was
nullable but not marked as such in the introspection data, such as the
`g_dbus_connection_get_peer_credentials` case you mention.

Cheers,
Iñaki