From #introspection:

<pclayton> hi, is there a reliable way to detemine whether an out parameter is written?
<pclayton> I am currently using the following heuristic:
<pclayton>   - if there is a BOOLEAN return value, this value indicates whether all the OUT parameters are written and
<pclayton>   - if there is not a BOOLEAN return value then all OUT parameters are written unconditionally
<pclayton> it seems to work - have I missed something though?
<pclayton> note that it is overly cautious, e.g. gtk_text_buffer_get_selection_bounds
<walters> pclayton, unfortunately not
<pclayton> I more interested in whether it is 'unsafe' anywhere
<walters> in my code i have a rule - if a function returns an error, none of the out parameters are set
<walters> and the converse is obviously true too: if a function returns successfully, all out parameters are set 
<walters> our stack doesn't consistently follow this though
<pclayton> walters: good point, I am talking about non-error cases only.  I wouldn't expect out parameters to be written when there is an error
<pclayton> but what you say about the converse is good to know.  Do you have any convention on how a flag is returned to indicate whether an out is written?
<pclayton> ah.. I've read that again and it sounds like you always write to outs when no error occurs.
<walters> that's right
<pclayton> there's a large number of gtk functions where the write is conditional...
<walters> or a better way to think of it is that the out parameter is well-defined
<walters> so for a string, it might be NULL if the API docs specify that's possible
<walters> but a key point here is that *if* we were successful, we *will* set it to NULL
<walters> so the user doesn't have to initialize it
<pclayton> I see.  I'm trying to avoid 'unknown' (possibly uninitialized) values leaking out of the gtk api I'm generating
<pclayton> it's not such an issue for scalar values but I'm certainly trying to avoid null pointers that could be subsequently dereferenced
<walters> for pointer types, just documenting it can be %NULL is sufficient i think
<pclayton> well.. my api is for standard ml - a functional programming language - so I'm not too sure the target audience would be happy about that :)
<pclayton> I'm trying to hide all details relating to pointers
<walters> doesn't one simulate "nullable types" in ML with Some x | None ?
* tomeu has quit (tomeu)
<pclayton> absolutely right!
<pclayton> I'm trying to do that everywhere
<walters> my standard ml and ocaml is long swapped out though for C/python/javascript though
<pclayton> but another characteristic of ML is that there are no uninitialized values, so I am also using SOME x | NONE for out parameters that may/may not be written
<walters> anyways if you need something from g-i like updated annotations, describing the use case, how you expect it to be used in bindings, and examples of current API in e.g. the GTK+ stack in a bugzilla report would be best
<pclayton> thanks, I will raise this in bugzilla as you suggest -
<pclayton> thanks, I will raise this in bugzilla as you suggest -
<pclayton> - I am thinking along the lines of proposing an extension to the (out) annotation e.g. (out cond-ret) or (out cond=X) where X is a parameter
<pclayton> (one thing I didn't say explicitly above but should have to be really clear: for ML, one really doesn't want SOME x | NONE for out parameters are written unconditionally or for pointers that are never null: the api would be considerably more usable if it has option types only where required, hence my question about determining the condition)
