Open arcnmx opened 2 years ago
The support for it is intentionally minimal because it's not a very useful type: for Rust code, use a Vec
and for FFI it's badly designed (see e.g. https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/305).
Why/where do you want to use it?
FWIW, for the next release I'm planning to get rid of the strange container FFI traits.
Any updates on this @arcnmx ?
I'm still using glib::ffi::g_ptr_array_xxx
manually here. Regarding the linked issue and related safety concerns, I suppose I'd opine that most methods can and should be bound, and at the very least it should impl the usual translate traits like FromGlib
/ToGlibPtr
(regardless of its contents, the array itself is fine to ref/unref as usual). The main question becomes what usage is considered unsafe... I see two main approaches here:
GPtrArray
with a NULL
free_func
.
Then transfer is irrelevant, there are no guarantees about the validity of any pointers contained, making it roughly equivalent to a Vec<gpointer>
in terms of usability and safety - the safety concerns only become an issue once it is passed to/from a function, crossing ffi.
new_full
/new_with_free_func
/set_free_func
would be considered unsafe, and would create an array value that needs to be kept private to ensure only valid pointers are added to it - it would be unsafe to hand out references to safe code (even retroactively)from_glib_full(ptr_array)
would only create a "safe" value if the underlying array is guaranteed to not have a free funcfrom_glib_full(ptr_array)
would (assuming it contains valid pointers and a valid free func) in most cases create a "safe" value, making it less dangerous to "expose" these values to pub
codegpointer
s out of the array without any type informationPtrArray::empty()
, impl Default for PtrArray
, impl FromIterator<gpointer> for PtrArray
, PtrArray::with_slice()
?, etc), and it could even expose helper constructors like PtrArray::with_objects()
that sets it up with set_free_func(g_object_unref)
I think I'm leaning toward option 2 personally? Future improvement here might mean introducing strongly-typed ObjectPtrArray<T>
wrappers or something to make these safe and actually useful to work with as arrays in Rust.
Personally I would go with the current situation and directly use FFI when these types are needed, and expose them per use-case in a meaningful way in Rust. As there are no general rules for these types, you'll basically end up doing that anyway unless you want to make life hard for your users.
The only way to interact with a
PtrArray
is to useToGlibContainerFromSlice
, a very unwieldy extension trait (honestly just implFromIterator
andExtend
instead?). It's impossible to even construct an empty array without doing some type gymnastics to invoke the trait. Its methods aren't bound at all, and the lack oftranslate
traits likeFromGlib
/ToGlibPtr
complicates its ownership as there's no public way to get a pointer to it once created.It's a bit of a complicated type due to the nature of its (lack of) memory management, but at least some ability to manipulate them would be nice!
EDIT: FromGlibPtrArrayContainerAsVec and friends are frankly horrifying.