imho this is a gobject-introspection (and bindings) shortcoming, so we can move discussion about it there.

In short, I think we should use (scope async) here with a very slightly tweaked meaning.

Right now (scope async) is documented as (more or less) "callback will be called exactly once".  I think a more natural way to think of it is "good until the async call has completed".  This works well since we have very strong conventions of what an async call looks like in our platform.

That would mean that secondary callback/userdata pairs could also be annotated (scope async) and the bindings would know that the user data must remain good until the async call is complete (ie: the GAsyncReadyCallback) fires.  That means, that just as with C usage, we would expect that this callback cleans up that data (which the binding could easily arrange through whatever trampolines it sets up).

Note that g_file_measure_disk_usage() suffers the same issues, and that we knew about this when designing that API...

(In reply to Ryan Lortie (desrt) from comment #1)
> Right now (scope async) is documented as (more or less) "callback will be
> called exactly once".  I think a more natural way to think of it is "good
> until the async call has completed".  This works well since we have very
> strong conventions of what an async call looks like in our platform.

You can use (scope async) on APIs that don't look like gio async calls though. (It's used for APIs that pre-date gio in libsoup, for example.)

But you could have the rule be:

  - if the function has a GAsyncReadyCallback, then (scope async) means
    "may be called any number of times, until the GAsyncReadyCallback has
    been called, which will happen exactly once"

  - if it doesn't have a GAsyncReadyCallback, then (scope async) means
    "will be called exactly once"

+1 on making this available to bindings.

CCing Philip since he was curious about this.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/127.