Use MaybeUninit for newly allocated samples

[elBoberido]

Since the data of the samples is not initialized, this should be reflected by the type system with MaybeUninit. The user then either has to use assume_init before sending the sample or it might be done under the hood. Alternatively MaybeUninit<T> could be transmuted to T.

[neilisaac]

Exposing &mut [u8] is also nice for compatibility with the bytes::BufMut trait.

For my use case I decided to build a fairly thin rust interface on top of the C bindings and am fairly happy with that approach so far. Happy to compare notes if you’re interested.

[elBoberido]

@neilisaac sorry for the late response. I was quite busy with the iceoryx v2 release.

Good idea. I'll add this to the API.

Did you use the current API? If yes, how does it feel? Would be great to get some feedback.

[neilisaac]

@elBoberido I found the C API fairly easy to use to build RAII abstractions for each entity. I built bindings for all C methods exposed but haven't integrated it with a production codebase (yet). To avoid adding noise to this issue, here's an example use of my rust bindings. I'm happy to chat if you're interested in comparing notes about the two approaches for rust support.

[elBoberido]

@neilisaac would be great. We have a bi-weekly developer meetup which could be used for discussion but we can also do it on gitter or github discussions.

My initial idea was to use the untyped C++ API and then try to replace part of the runtime with native Rust code. Maybe it is more pragmatic to just use the C API and create a nice Rust API around it.

I have to think about the Listener though. It spawns internally a thread and I'm not quite sure if it is easy to create a safe abstraction around this construct.

That said, would be great to get some input and/or code from you.

[neilisaac]

I posted some more details in this discussion: eclipse-iceoryx/iceoryx#1304