Created attachment 287813 [details] [review]
Added function g_iconv_convert()

This might be easier to generate bindings for than g_iconv().

Created attachment 287814 [details] [review]
Make g_iconv() non-introspectable

To introspect the parameters of g_iconv() with any pretense of
accurateness, one would have to use Christmas tree annotations
like (inout) (nullable) (optional) (array length=inbytes_left),
and solve the riddle of ownership transfer modes as applied to
inout parameters. That would make binding generators flee in panic.

Now saner, cuter, g_iconv_convert() is provided instead.

(In reply to comment #1)
> Created an attachment (id=287813) [details] [review]
> Added function g_iconv_convert()

The parameters could be reshuffled so that each output parameter follows its respective array parameters, if that order looks better.

Created attachment 287873 [details] [review]
Bikeshed the order of parameters on g_iconv_convert()

It's perhaps more intuitive if each output parameter follows
its respective array parameters.

Do you have a specific usecase for iconv from a bound language?

These days I've found this 'full strength' iconv API to be pretty much only used for:

 - conversion to/from the user's locale and utf8 (which is 99%
   of the time a no-op)

 - transliteration from utf8 to ascii (which we have better APIs to cover now)

Even at a stretch, we are probably only ever converting between utf8 and some other locale.

In pretty much every use case, as well, we only want to do this in one shot (ie: we don't need the streaming API).

Maybe we could benefit from creating a more constrained API.

(In reply to comment #5)
> Do you have a specific usecase for iconv from a bound language?

One of the many neat things about Rust is you can use it in a freestanding #[no_std] mode - it would be possible to write a library which was a hybrid of C and Rust, with the Rust code calling C for everything beyond pure computation/data structures, and not having any external dependencies.

Beyond that, I'm guessing Rust's libstd doesn't have iconv?

> In pretty much every use case, as well, we only want to do this in one shot
> (ie: we don't need the streaming API).

We do also have GCharsetConverter which can be used for streaming (albeit, this is all pretty heavyweight).
 
> Maybe we could benefit from creating a more constrained API.

Probably in addition?

(In reply to comment #5)
> Do you have a specific usecase for iconv from a bound language?

No specific need for iconv. I want to ultimately generate Rust bindings for the entire GIR of the GLib libraries, so I'd like to avoid generation of wrong or unusable APIs with as little manual intervention as possible. The main problem is that many things get automatically mistyped as UTF-8 (Rust's built-in strings are UTF-8, so ultimately fast no-validation value transfer is possible from GLib to Rust as long as the string types are annotated correctly), and/or have no proper annotation for out parameters, nullability, and the like. I'm combing through GLib code to prepare a larger set of annotation patches to submit later (the WIP branch is meanwhile available at https://github.com/mzabaluev/glib/commits/wip/annotations).

g_iconv() just happens to be so weird that it's better not introspected at all, but it felt wrong to make the functionality inaccessible when there is an easy workaround. I lack the insight to tell if no other language binding would have a need for it. Rust certainly can have a more idiomatic direct binding for iconv any day someone wants to create it, and it's easy to do. So it's totally OK for the time being to live without introspectable GLib iconv access as far as I'm concerned.

I'd prefer to just mark the API as non-introspectable then.  Colin: thoughts?

Created attachment 288019 [details] [review]
Make g_iconv() non-introspectable

Erased the mention of g_iconv_convert() so that the patch can be
applied alone.

I have now submitted a more thorough fix in bug #756128.