Somewhat experimental idea, needs validation, also see #68:
Names tbd:
- A generic FFIPointer<T, SingleElementOrMultiple, RustRW, FFIRW> indicating how that pointer is being used (type T of target, single or multiple elements, and who reads and writes; bonus points if we can make T so that it also accepts and enum of type alternatives although I wouldn't know how to do that)
- various aliases to common FFIPointer<A, B, C, D> combinations.
- The generic FFIPointer would fallback to *T or *c_void in backends for now or could be used for other optimizations (e.g., deciding if an #[In, out] should be applied.
- bonus-bonus points if MultipleElements can also encode variable or constant many elements.
This pointer could also subsume Callbacks with the help of const generics, e.g., Callback<Name="Bla"> once &str are available.
Main questions to resolve are:
- Can this be implemented?
- Will this make writing APIs more ergonomic (e.g., better C# bindings w.r.t
IntPtr, #[In/Out], ...)?
- Will this be cleaner or more messy than having multiple independent types (e.g., w.r.t. our maintenance)?
Somewhat experimental idea, needs validation, also see #68:
This pointer could also subsume
Callbackswith the help of const generics, e.g.,Callback<Name="Bla">once&strare available.Main questions to resolve are:
IntPtr,#[In/Out], ...)?