After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758903 - Add transfer annotations
Add transfer annotations
Status: RESOLVED OBSOLETE
Product: dconf
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: dconf-maint
dconf-maint
Depends on: 742618
Blocks:
 
 
Reported: 2015-12-01 14:46 UTC by Xavier Claessens
Modified: 2018-08-08 11:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add some transfer annotations (6.43 KB, patch)
2015-12-01 15:15 UTC, Xavier Claessens
needs-work Details | Review

Description Xavier Claessens 2015-12-01 14:46:22 UTC
DConfClient and DConfChangeset APIs never tells if they return new reference, if they sink floating variants, etc.
Comment 1 Xavier Claessens 2015-12-01 15:15:24 UTC
Created attachment 316608 [details] [review]
Add some transfer annotations
Comment 2 Allison Karlitskaya (desrt) 2015-12-01 17:02:41 UTC
Review of attachment 316608 [details] [review]:

Let's wait on this until the (transfer consume) patch is ready.

::: client/dconf-client.c
@@ +402,3 @@
+ * @value: a #GVariant, the value to write. If it has a floating reference it's
+ *  consumed.
+ * @tag: (out) (allow-none) (transfer full): the tag from this write

Hm.  This should say 'nullable' these days :)

::: common/dconf-changeset.c
@@ +77,3 @@
  * Creates a new, empty, #DConfChangeset.
  *
+ * Returns: (transfer full): the new #DConfChangeset.

Annotating _new() as transfer-full is a bit overboard, imho.
Comment 3 Philip Withnall 2015-12-09 15:24:04 UTC
(In reply to Allison Ryan Lortie (desrt) from comment #2)
> Review of attachment 316608 [details] [review] [review]:
> 
> Let's wait on this until the (transfer consume) patch is ready.

Bug #742618, I think?

Given that #742618 last saw activity in February, can we go with “perfect is the enemy of good”, review and commit this patch now so it doesn’t rot, and do the (inevitable anyway) round of changes from (transfer full) to (transfer consume) once bug #742618 is fixed?

> ::: common/dconf-changeset.c
> @@ +77,3 @@
>   * Creates a new, empty, #DConfChangeset.
>   *
> + * Returns: (transfer full): the new #DConfChangeset.
> 
> Annotating _new() as transfer-full is a bit overboard, imho.

But necessary, because there are no heuristics about ‘*_new()’ functions automatically being (transfer full), IIRC.
Comment 4 Xavier Claessens 2015-12-09 16:25:15 UTC
(In reply to Philip Withnall from comment #3)
> (In reply to Allison Ryan Lortie (desrt) from comment #2)
> > Review of attachment 316608 [details] [review] [review] [review]:
> > 
> > Let's wait on this until the (transfer consume) patch is ready.
> 
> Bug #742618, I think?
> 
> Given that #742618 last saw activity in February, can we go with “perfect is
> the enemy of good”, review and commit this patch now so it doesn’t rot, and
> do the (inevitable anyway) round of changes from (transfer full) to
> (transfer consume) once bug #742618 is fixed?

When Allison said that she was actually doing the patch for (transfer consume), so let's giver her a chance to finish that. That API isn't introspected yet and is going to be copied into glib itself soon, so it's not a big deal if this patch gets lost for now.
Comment 5 Philip Withnall 2018-08-08 11:08:50 UTC
I found some mails about this hiding in my Bugzilla folder, so took a few minutes to update it.

Merge request now open on GitLab: https://gitlab.gnome.org/GNOME/dconf/merge_requests/9

Let’s close this and track progress there.