On Fri, 2018-02-09 at 07:49 +0000, philip chimento gmail com wrote:
Next up! (I think this is the last of my Bugzilla-migration-triggered mail series.) Transfer rules of inout parameters: https://gitlab.gnome.org/GNOME/gjs/issues/95 https://gitlab.gnome.org/GNOME/gobject-introspection/issues/114 tl;dr: some time ago a commit to gobject-introspection broke a test in GJS and I've never been able to figure out whether gobject- introspection or GJS is wrong. I always thought inout worked like this: a function with an inout parameter /* inout: (transfer full): */ void func(char **inout) { g_assert (strcmp (*inout, utf8_const) == 0); g_free (*inout); *inout = g_strdup (utf8_nonconst); } should have exactly the same transfer rules as a function with two separate parameters /* in: (transfer full): * out: (transfer full): */ void func2(char *in, char **out) { g_assert (strcmp (in, utf8_const) == 0); g_free (in); *out = g_strdup (utf8_nonconst); } That, at least I think, is how gobject-introspection specifies it (de facto, by virtue of the code working like that.) GJS interprets it as in: (transfer none) out: (transfer full) and Giovanni commented on that bug, that he thought existing libraries required that interpretation. The test in GJS has been commented out for 2 years waiting for me to figure this out. Does anyone know?
I don’t know what the original interpretation was meant to be, but here’s an off-the-wall idea: • Deprecate (inout). • Instead, allow separate annotations for the ‘in’ and ‘out’ modes for a parameter; something like (in (nullable) (transfer none)) (out (not nullable) (transfer full)). • That’s because quite a few of the annotations could theoretically differ between the modes: nullability, transfer and array length. • Because this is tricky to reason about, don’t have a default: require that everything is always specified for inout parameters. • My suggested syntax is horrible. Alternatively, if an audit of all our inout parameters shows that they all have (for example) the same nullability and array length for in and out modes, we could go with something simpler like (inout TRANSFER-IN TRANSFER-OUT). Any APIs which have more complex inout parameters should be considered un-introspectable, and would have to be replaced with another API which splits the inout parameter in two in order to be bindable. Thanks, Another Philip
Attachment:
signature.asc
Description: This is a digitally signed message part