Created attachment 354137 [details] [review]
GKeyFile – Add array length annotations to to_data(), get_keys() and get_groups()

Review of attachment 354137 [details] [review]:

++

Attachment 354137 [details] pushed as fd329f4 - GKeyFile – Add array length annotations to to_data(), get_keys() and get_groups()

Turns out that this change breaks the introspection ABI, and led to a change in GNOME Shell to cope with it, which means it may have broken every single introspection-based language.

Ideally, all these functions should *not* have a length out argument: the array they return are all NULL-terminated.

I'm going to revert the commit in master, and we're going to figure out what to do.

That basically means that we can never fix any annotations that are wrong but not completely broken, most of which probably happened because they were just missed. With real API this won't happen, but annotations can easily be forgotten.

For the Rust bindings we will just have configuration now to override the annotations at the code generator level, but it's a bit suboptimal if every binding has to do that. Especially for bindings generated at runtime like GJS and Python, which also have the disadvantage that new typelibs will be updated without review as compared statically generated bindings where someone actually goes over the changes between versions (or at least one would hope so...).

Also generally this means that annotations can never be changed/improved unless they were just plain broken. As you can never know what considers of an API/ABI change for any of the bindings out there.


What would you suggest for solving this? Adding version/epoch numbers to annotations that are independent of the library version, and bindings/applications would select which they want to use?

Yeah, it's unfortunate.  I don't think there's one single solution; sometimes adding a new C API could make sense.  In others, papering it over in the bindings.

It hurts my head to think about a version/epoch scheme.

In this case I think my vote would be that we just live with the API.

Fine with me, it's just annoying :) Maybe GI should've been opt-in for every single piece of API instead of just generating everything, possibly wrongly. Too late now

Have we actually committed to API stability for any GI bindings?

Pretty much, yes: it's far too late to break stuff, these days.

I guess the fix here then is going to be to paper over the damage in each language’s bindings, depending on what API guarantees they provide to their users. :-(