Created attachment 242007 [details] [review]
GVariant: add new g_variant_new_take_string() API

Lots of people have variously asked for APIs like
g_variant_new_string_printf() in order to avoid having to use
g_strdup_printf(), create a GVariant using g_variant_new_string(), then
free the temporary string.

Instead of supporting that, plus a million other potential cases,
introduce g_variant_new_take_string() as a compromise.

It's not possible to write:

 v = g_variant_new_take_string (g_strdup_printf (....));

to get the desired result and avoid the extra copies.  In addition, it
works with many other functions.  An upcoming patch for GIcon intends to
do the same with g_strjoinv().

Comment on attachment 242007 [details] [review]
GVariant: add new g_variant_new_take_string() API

>It's not possible to write:

It's NOW possible

>+ * g_variant_new_take_string: (skip)

For any binding that is actually just wrapping GVariant rather than binding it specially, it would probably be better to mark g_variant_new_string() as (skip) and this as "Rename-To: g_variant_new_string".

Review of attachment 242007 [details] [review]:

::: glib/gvariant.c
@@ +1288,3 @@
+ * it to this function.  It is even possible that @string is immediately
+ * freed.
+ *

Returns: (transfer none): a floating reference to a new string #GVariant instance

Attachment 242007 [details] pushed as dbb65b5 - GVariant: add new g_variant_new_take_string() API

Pushed with the change, thanks.

Missed your review, Dan :(

I guess I have to live with the bad commit message forever....


Meanwhile, what do you mean about the rename-to business?  It seems that functions that consume their first argument are not the most bindings-friendly things....

um... yeah. not sure what i was thinking, but it was clearly wrong...

FIXED, then.  Thanks.