This is a list of things I wish were different in a future version of GLib. Most likely with an ABI and API break.
GLib currently uses wrapper types such as gint, glong, guint32, etc. The are nice and portable, but look weird to anyone not inducted in the house of GLib.
C99 types are here and usable in most places. The places where it does not seem to be fully available are the following.
- Windows
- Some embedded systems. Can we get a list from current users?
- Ancient LTS Linux systems (RedHat 7.3 is still used in scientific institutions and clusters and things).
The main thing here is that we can pretty well emulate C99 types in most cases here. Windows is our typical pain-in-the-ass platform and it can mostly be done there.
We continue to be C89 compatibile, but use C99 types as if they are available. To do this we can make a compatability header for systems that do not support them. We do have one exception, "long long" is a C99 type that cannot be supported with a header so I would suggest it does not get used.
We should also move to PRId32 and other format strings.
Today, GLib does not contain the type system. That is part of GObject, which is a type system built upon GLib. Most of our platform libraries are built on GObject so they can have Object Oriented semantics and cross-language integration.
GObject, boxed types, values and such are moved into GLib and the GObject library is dropped. The type system will exist in GLib and GLib data structures will also use them.
Today, in GLib, data structures all implement their own reference counting and resource management. GObject's do a lot of this as well but are too slow and too bloated to be used by the data structures (even if GObject was part of GLib).
Create a lightweight object that would be even lower than GTypeInstance/GObject that can serve as the base for reference counted data structures. An example might be GQueue, GHashTable, etc. Pure data structures should not need to integreate here, such as GList and such.
Everything implements it's own reference counting today, except GObject's. You don't necessarily even know if it is thread-safe or not.
Reference counted structures use GReffable (or some other base class underneath GObject). g_ref() and g_unref() could be used for succinctness.
When the type class is registered, a flag can be provided to denote that the structure needs to be thread-safe. Or possibly, invert that so it may say that it is not thread safe (for good defaults).
The VTable used for reference counting would be swapped to a ++/-- implementation rather than costly atomics. This should include some imperical evidence that shows that the extra vtable dereference is faster than the atomic costs.