b4n commented on this pull request.
This looks good, and useful. However, which impact does it have on performance for dynamic languages which would likely always ref/unref through the `GBoxed` API, even when not actually needed. Or are Python and other GType bridges smarter than that and only copying when really required?
@@ -82,7 +82,11 @@ typedef struct
gboolean first; } TMSortOptions;
-/* Gets the GType for a TMTag */ +/** Gets the GBoxed-derived GType for a TMTag.
Should we advertise it's derived from GBoxed? C code should probably have access to `tm_tag_ref()`/`tm_tag_unref()` instead as it has more meaningful semantics as `g_boxed_copy()`, and generic code can figure it out by itself looking at the type information. And advertising GBoxed means it's kind of stuck to that implementation -- which is likely to say indeed, so I'm probably nitpicking, but we could want to change that one day.
Anyway, that's not a so important point.
@@ -82,7 +82,11 @@ typedef struct
gboolean first; } TMSortOptions;
-/* Gets the GType for a TMTag */ +/** Gets the GBoxed-derived GType for a TMTag. + * + * @return TMTag type + * @since 1.31 (API 232) */
unfortunately that probably will have to be updated